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 discloses that the tool executes :AUToset and explains option effects, including that lock_timebase disables the AUTO function, but it does not state that autoscaling changes instrument state broadly, what happens to existing settings, or whether a connected instrument is required.

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

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

The description is front-loaded with the main operation, then uses a compact parameter list. Most sentences earn their place, though the manual reference and some parenthetical details are slightly dense rather than optimally trimmed.

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. However, with no annotations, the description should carry more behavioral context than it does; it covers parameters and execution but omits side effects, prerequisites, and usage routing.

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

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

Schema description coverage is 0%, so the description must compensate, and it does document all five Boolean parameters with practical meanings. Four parameters explicitly map True/False behavior, while peak_search lacks a clear True/False mapping and null/default behavior is not explained.

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 operation: configure Autoset options and then execute :AUToset. This distinguishes it from siblings that only set or get Autoset options, because it actually performs the autoscale action. It could more explicitly name the sibling tool set_autoset_options as the configuration-only alternative.

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

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

The description explains what each option does but gives no when-to-use guidance, prerequisites, or comparison to alternatives such as set_autoset_options. An agent can infer it is for autoscaling with options, but there are no exclusions or alternative-routing statements.

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 state what gets destroyed (event registers and error queue are cleared), which is useful behavioral context. However, it doesn't disclose whether this affects instrument operation state, whether the error queue is permanently lost, or the effect on related status structures.

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 waste. The verb and effect are stated immediately and the SCPI mnemonic is included compactly.

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 an output schema, the description needn't explain return values. The main gap is the lack of guidance on when to use this versus reset or get_errors, and limited behavioral detail about side effects on instrument state.

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?

Zero parameters, so baseline is 4. The description adds the SCPI mnemonic *CLS, which is helpful context beyond the empty schema, though there are no parameters to document.

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: clearing event registers and error queue via the *CLS SCPI command. This distinguishes it from siblings like reset, self_test, and get_errors, though the description doesn't explicitly contrast with them.

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

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

No guidance on when to use this tool versus alternatives. An agent cannot tell from the description whether to call clear_status versus reset or get_status, nor when clearing is appropriate.

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

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

With no annotations, the description bears the full load and discloses real behavioral traits: parameter precedence between frequency and period, absolute-level coupling constraints, per-waveform frequency ceilings that change with impedance and above 50 MHz, and channel mapping to SOURce1/2. It does not say whether unspecified optional parameters are left untouched or cleared, nor whether the output must already be enabled.

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-loaded with purpose and function, then organized parameter-by-parameter; almost every line carries a unit, range, or override rule. The function enumeration is long but justified because the schema supplies no enum, though the presentation is dense enough to slow scanning.

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 explanation, and the description covers the mutation's constraints and the required channel's valid values (GI/GII). The remaining gap is behavior for omitted optional settings and any prerequisite state, which an agent may need before calling a 13-parameter write.

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 13 parameters, so the description carries the full burden and does so: it gives units, ranges (frequency 2 mHz-100 MHz with per-waveform caps, period 10 ns-500 s, amplitude 1 mV-20 V, phase 0-360), aliases for impedance, and the load_arbitrary path conventions. It also encodes non-obvious rules the schema cannot express (period is written last and wins; high must stay above low; DC/Noise ignore frequency).

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 instrument semantics ('Configure generator channel GI/GII (SOURce1/2)'), so the agent knows this sets AWG channel output parameters. It also names the two sibling tools that cover adjacent operations (sync_awg_phase, get_awg_full_config), which separates it from 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?

Explicitly routes two adjacent cases to siblings: align-phase belongs to sync_awg_phase(), and reading all settings belongs to get_awg_full_config(). It does not address when to prefer this over configure_awg_modulation, so the routing is clear but not exhaustive.

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

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

With no annotations, the description carries the full burden and does disclose useful behavioral constraints: fm_deviation_hz is bounded by the current carrier frequency, and the 'extra' dict only accepts documented MOD subsystem keywords (case-insensitive, canonicalized). However, it never says whether this is a pure write, whether it requires the AWG/output to be active, or what the required 'channel' and 'enable' flags do.

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?

Dense and front-loaded, leading with the core purpose before enumerating constraints. Some lines (manual section numbers, bare range fragments) are terse to the point of being cryptic, but there is little wasted text.

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 for a 13-parameter mutation tool the description omits the required channel parameter and the enable flag entirely, which an agent needs in order 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?

Schema description coverage is 0%, so the description must compensate; it does give units and ranges for am_depth_percent, fm_deviation_hz, pm_deviation_deg, internal frequency, and the waveform shape list, plus the 'extra' whitelist semantics. But it entirely omits the required 'channel' parameter, the 'enable' flag, and how am/fm/pm_internal_function and *_internal_frequency map to each modulation type, leaving substantial gaps.

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

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

States a specific verb+resource: configuring generator modulation (AM|FM|PM) on the AWG, with a manual citation. It is clearly distinguishable from the broader configure_awg/set_awg_output siblings, though it never explicitly names them as 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?

No statement of when to use this tool versus configure_awg, set_awg_output, or sync_awg_phase, and no prerequisites (e.g., must the AWG output already be enabled?). The manual section reference is not usage 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 must carry the behavioral burden. It discloses useful constraints (start*10 <= stop, voltage ranges, gain/phase curves settable only while stopped), but omits what run and enable do and whether changes are immediate or reversible 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?

Front-loaded with the tool purpose and prerequisite, then organized as concise per-parameter lines. It is dense but appropriate for a 12-parameter tool; no sentence is wasted on 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?

An output schema exists, so return values need not be explained. However, the description omits run/enable semantics and gives no routing guidance versus get_bode_config, leaving gaps for a complex, annotation-free mutation 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?

Schema description coverage is 0%, so the description must compensate, and it does for 10 of 12 parameters: sweep_type aliases, ref_in/ref_out channel forms, frequency bounds, points range, voltage bounds, voltage_range forms, and the stopped-state condition. It omits run and enable entirely, which is a notable gap in an otherwise rich parameter explanation.

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

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

States a specific verb+resource: 'Bode plot configuration'. The purpose is clear from the name and description, but it does not explicitly differentiate from the sibling get_bode_config, which reads the same 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?

The description states a prerequisite ('requires generator option') and a manual reference, but gives no explicit when-to-use guidance relative to alternatives such as get_bode_config or configure_awg. Usage is only implied by the configuration verb.

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

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

With no annotations, the description carries the full burden and does well: it states that every None argument is left unchanged, that typing is routed to the active protocol, that omission of protocol triggers a query of the current mode, and that unknown keywords are validated against a manual-derived whitelist. It omits permission/auth requirements and the write's reversibility, but the mutation and defaulting semantics are unusually well disclosed.

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

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

The text is long, but for a 16-parameter tool spanning ten protocols the density is justified, and the top line is front-loaded with the core purpose followed by structured bullet groups. Minor redundancy (repeated protocol lists) keeps it from a 5, but almost every line 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?

Given high complexity, no annotations, a zero-documentation schema, and an output schema that handles return values, the description supplies everything needed to call the tool correctly: parameter semantics, routing, defaults, legal values, and the escape hatch. Nothing an agent needs 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 0% and all 16 parameters have bare titles, yet the description compensates fully: it documents display, format, event, label, position, threshold/threshold_type (with legal types and voltage range), source, baud (with per-protocol ranges), dbits, parity, polarity (incl. cross-spelling mapping), endian, and the 'extra' sub-path mechanism with per-protocol legal keywords. This is exemplary compensation for a zero-coverage 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 gives a specific verb and resource ('Configure decoding bus BUS1..BUS4') and enumerates the covered settings, so the agent knows exactly what the tool does. However, it never distinguishes itself from the many protocol-specific siblings (configure_bus_parallel, configure_bus_rs232, configure_bus_iic, etc.), so the agent must infer whether this generic entry point is preferred over 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?

Usage is implied through the routing rules (protocol= selects and routes typed params; if omitted the current mode is queried first) and the 'extra' escape hatch, which conveys how to call it. But there is no explicit when-to-use/when-not guidance and no mention of the dedicated configure_bus_<protocol> alternatives, leaving the agent to guess which tool to pick.

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 default values and valid ranges (e.g., baud default 1 Mbps, sample_point default 80), but says nothing about side effects such as overwriting existing bus configuration, whether acquisition must be stopped, permission requirements, or idempotency.

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 purpose is front-loaded in one sentence, followed by a compact per-parameter list where every line carries distinct information. No filler; the manual reference is the only ancillary detail and is brief.

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 explanation, and the parameter semantics are thorough. What remains missing for a no-annotation configure tool is prerequisite/ordering context and any caution about reconfiguring a bus already in use.

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

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

Schema description coverage is 0% and all 8 parameters are undocumented in the schema, yet the description compensates fully: it specifies units and ranges for baud/fd_baud, the enum choices for signal_type (TX|RX|CANH|CANL|DIFFerential), the numeric range for sample points, and the meaning of display — plus defaults for the key 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 first sentence gives a specific verb and resource ('Set Bus <n> to CAN/CAN-FD decoding and configure it'), which unambiguously distinguishes this tool from the many sibling protocol configurators (configure_bus_spi, configure_bus_iic, configure_bus_lin, etc.). An agent can identify CAN/CAN-FD decoding setup without opening the 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 implied by the purpose (use it to set up a CAN bus for decoding), but there is no explicit when-to-use guidance, no mention of prerequisites such as connecting to an instrument, bus enablement, or ordering relative to configure_bus / read_bus_data. No alternative tool is named or excluded.

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 of behavioral disclosure. It mentions a manual section but says nothing about mutability, side effects, required device state, or whether existing bus configuration is replaced. For a configuration tool with seven parameters, this is a significant gap.

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

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

The definition is front-loaded with the core action, then lists parameters in a compact, scannable format. Every line earns its place, and the manual reference adds useful traceability without wasting space. No redundant or filler sentences.

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. The description covers purpose and parameter semantics well, but it omits behavioral context needed to invoke safely (e.g., state requirements, side effects) and lacks any usage routing among the many configure_bus_* siblings. It is adequate for correct invocation but incomplete for confident selection.

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

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

The description provides explicit meaning for every parameter: allowed values, ranges, and defaults (e.g., baud '2500000|5000000|10000000 bps (default 10000000)', sample_point '10..90 in % (default 50)'). It even documents the required bus parameter via 'Set Bus <n>'. This fully compensates for the 0% schema description 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 states a specific verb and resource: 'Set Bus <n> to FlexRay decoding and configure it.' It explicitly names the protocol (FlexRay), which differentiates it from siblings like configure_bus_can or configure_bus_spi. An agent can immediately tell what the tool does without opening the 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?

There is no guidance on when to use this tool versus alternatives such as configure_bus or other protocol-specific bus configurators. The description only states the action, not the context or prerequisites (e.g., must acquisition be stopped, does it overwrite existing bus settings). No when-not or alternative routing is provided.

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

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

No annotations are provided, so the description carries the full burden. It does disclose a default (addr_bits default 7), the meaning of exchange (swaps channel sources), and that display enables the decoding bus — useful behavioral detail. However it is silent on persistence across power cycles, whether reconfiguring an already-configured bus resets other settings, and any error behavior.

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

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

Front-loaded purpose line, then one compact line per parameter with no filler or restatement of the tool name. 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?

An output schema exists, so return values need not be explained, and the parameter set is well covered. What remains thin is the surrounding workflow context — prerequisites, interaction with configure_bus_get_bus_config, and state side effects — which a mutation tool with no annotations could reasonably supply.

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 this description is doing the work: it supplies allowed value families (CH1..CH4 or D0..D15), the addr_bits value set 7|8|10 with default 7, and the semantics of exchange and display. Only the required 'bus' parameter (self-evident from the name) is left undocumented, hence not a perfect 5.

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 ('Set Bus <n> to I2C decoding and configure it') and the protocol name distinguishes it cleanly from the many siblings (configure_bus_spi, configure_bus_can, configure_bus_iis, etc.). An agent can select this without opening any 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?

The description implies the setup role (decode configuration must precede read_bus_data) but never states when to use this versus configure_bus / configure_bus_parallel / read_bus_data, nor any prerequisite such as enabling the bus first. 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?

No annotations are provided, so the description carries the full behavioral burden, and it does not disclose what happens to existing bus settings when called, whether configuration is applied immediately or on next acquisition, whether it must be persisted via save_setup, or any permission requirements. The only behavioral hints are the stated defaults (alignment IIS, endian MSB), which is thin 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?

Purpose is front-loaded in the first line, followed by a compact, one-line-per-parameter reference block where each line adds meaning. There is little waste, though the breakneck abbreviation style (e.g., 'ws_low: LEFT|RIGHt') is dense.

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 values need not be explained, and the description covers nearly all 12 parameters plus the tool's purpose. What is missing is the behavioral layer (side effects, persistence, preconditions), which matters for a configuration mutation with no annotations, keeping it short of a 5.

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% (titles only), so the description must compensate, and it does so well: it explains the meaning and accepted values of clock/data/ws_select, alignment, clk_slope, word_width, receive_width, ws_low, endian, polarity, and display. The notable gap is the required 'bus' parameter itself, whose valid range/identifiers are never described.

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 opening sentence gives a specific verb ('Set'), a specific resource ('Bus <n>'), and the exact mode ('I2S decoding'), which inherently distinguishes it from the many protocol-specific siblings such as configure_bus_spi, configure_bus_can, and configure_bus_iic. An agent can route to this tool from the name and first sentence alone.

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 never states when to use this tool versus alternatives, nor any precondition such as whether the bus must be stopped or the acquisition halted before reconfiguring. Usage can only be inferred from the protocol name. No mention of configure_bus or get_bus_config as related steps.

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 states defaults for standard and baud, but says nothing about what happens to an already-configured bus, whether mutation is reversible, whether it requires the instrument to be stopped, or any permission/state requirements. For a mutation tool with zero annotation coverage this is a significant gap.

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

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

Purpose is front-loaded in the first sentence and the remaining lines are a compact one-line-per-parameter list. Efficient, though the parenthetical manual reference and the mixed sentence style are slightly informal.

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 all parameters are covered. However, for a state-mutating configuration tool with no annotations, the description omits interaction with existing bus state and any preconditions, leaving the agent to infer behavior.

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

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

Schema description coverage is 0%, so the description must compensate, and it does: it documents all six parameters including source valid ranges (CH1..CH4 or D0..D15), standard enum values (V1X|V2X|MIXed) with default, baud range and units with default, and the meaning of parity and display. This adds real meaning beyond the bare titles in the schema.

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

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

States a specific verb (configure/set) and resource (Bus <n> for LIN decoding), and the protocol name distinguishes it cleanly from the many sibling configure_bus_* tools (CAN, SPI, IIC, RS232, etc.). An agent can select it without opening the 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 implied by the protocol-specific naming and the manual reference (3.4.15), but there is no explicit when-to-use guidance, no statement of prerequisites, and no mention of when to prefer the generic configure_bus or get_bus_config instead. Adequate but with clear gaps.

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 transparency burden. It discloses that this enables decoding and defines source/display behavior, but does not mention side effects, overwrites, required state, or other operational constraints.

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-loaded purpose followed by parameter notes and a useful routing note for threshold configuration. It is concise and skimmable, though the fragment style and manual citation are slightly rough.

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?

Output schema exists, so return values need not be described. However, with no annotations and 0% schema description coverage, the description leaves gaps: the bus parameter range/meaning, defaults, and preconditions are not addressed.

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

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

Schema description coverage is 0%, so the description must compensate. It explains source options (CH1..CH4 or D0..D15) and display meaning, but does not define the required bus parameter beyond the vague '<n>' placeholder.

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: setting a bus to MIL-STD-1553B decoding and configuring it. The tool is clearly one of the bus-protocol configuration siblings, and the manual reference reinforces scope.

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 by the tool name and the phrase 'Set Bus <n> to MIL-STD-1553B decoding.' It explicitly redirects differential-threshold configuration to configure_bus, but does not state when to prefer this tool over other bus configuration tools or what prerequisites exist.

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 does disclose useful traits: manual-derived defaults (endian NEGative default), the analog-source width restriction (1..4), and that display 'enable[s] the decoding bus' (a visible side effect). However, it never says whether configuring overwrites an existing bus setup, whether other bus settings are reset, or what the response looks like.

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?

Purpose is front-loaded in one line, followed by a scannable parameter list where each line earns its place. Slightly dense and the indented continuation lines ('(USER enables the per-bit sources below)') are a little awkward, but there is 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?

An output schema exists, so return values need not be described. For a 10-parameter, zero-coverage config tool the description is strong on parameters and adequate on behavior; the only real gap is the absence of any statement about how this configuration interacts with pre-existing bus settings.

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 schema has no enums, so the description must carry all semantics — and it does. It documents every one of the 10 parameters with concrete allowed values (bus_source D7D0|D15D8|...|USER, clk CH1..CH4|D0..D15|OFF, clk_slope POS|NEG|BOTH, width 1..16, bit range 0..width-1, endian, polarity, display) and flags the cross-parameter dependency between bit_source and BUS_source.

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 opening sentence states a specific verb and resource: 'Set Bus <n> to PARallel decoding and configure it,' with a manual section reference. Against a sibling set full of configure_bus_rs232/iic/spi/can/lin/etc., the word PARallel uniquely identifies which bus protocol this tool configures.

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 by the protocol name but never stated: there is no 'use this when decoding a parallel bus' and no comparison to the other configure_bus_* siblings. The per-parameter notes ('USER enables the per-bit sources below', 'BUS_source must be USER') give conditional guidance, but only at the parameter level, not tool selection.

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 discloses useful behavioral facts: defaults for polarity/endian/baud/dbits/sbits, and the constraint that tx and rx cannot both be OFF, plus that display enables the decoding bus. However it says nothing about permissions, whether existing config is overwritten, or side effects on other buses, so it's only partially transparent 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?

Purpose is front-loaded in the first sentence, followed by a compact parameter reference with no filler. Every line 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?

An output schema exists, so return values needn't be explained, and all ten parameters are documented. The only shortfall is the absence of usage context and side-effect disclosure, minor given the strong parameter 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% across 10 parameters, so the description must compensate and does: it enumerates valid values and defaults for tx/rx (CH1..CH4 or D0..D15, rx OFF), polarity, parity, endian, baud range, dbits, sbits, and display. This is exactly the value-add a description should provide over an undocumented schema.

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

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

States a specific verb (Set/configure) and resource (Bus <n> to RS232/UART decoding), which cleanly distinguishes it from the many sibling configure_bus_* tools (iic, spi, can, lin, etc.). The manual reference (3.4.11) anchors it further.

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

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

The purpose sentence implies when to use it (configuring RS232/UART decoding on a bus), but there is no explicit when-to-use vs. alternatives guidance and no stated prerequisites. Sibling naming makes the routing obvious, so it's adequate 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?

No annotations are provided, so the description carries the full behavioral burden. It discloses several important constraints: 'miso/mosi may be OFF but not both', 'timeout_s must exceed max clock pulse width', 'ss only in CS mode', 'ss_polarity only in CS mode', and defaults for dbits/endian/mode. However, it omits mutation scope (does it reconfigure an existing bus or create one?), whether configuration is persistent, and side effects on active acquisition. Given no annotations, this is more than a bare-bones description but still incomplete on mutation semantics.

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?

Structured as a one-line purpose followed by a parameter block in a consistent 'name: meaning' format. Front-loads the action, then enumerates parameters. Slightly dense but every line earns its place given 13 undocumented parameters.

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 13 parameters, 0% schema coverage, no annotations, and an output schema present (so return values need not be explained), the description supplies the parameter details the schema lacks. It omits when-to-use versus other bus tools and behavioral scope of the mutation, but for a configuration tool this is close to complete.

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

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

Schema description coverage is 0% – the schema provides only types and no text descriptions. The description fully compensates by defining every one of the 13 parameters: sclk/clk_slope/miso/mosi/polarity/dbits/endian/mode/timeout_s/ss/ss_polarity/display, with value ranges and defaults. This is exactly the case where the description must carry parameter semantics, and it does so exceptionally well.

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+setting: 'Set Bus <n> to SPI decoding and configure it'. The protocol is explicit (SPI) and the operation (set/configure) is clear. Among sibling configure_bus_* tools, the SPI variant is distinguishable by the protocol name in the tool name and description.

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

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

The description implies this is the SPI-specific configuration tool, with sibling tools for other protocols (configure_bus_parallel, rs232, iic, can, etc.) named in the tool list. However, it does not explicitly state when to choose SPI config versus the generic configure_bus, nor does it give preconditions or exclusions. Usage is implied by the protocol name rather than spelled out.

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

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

With no annotations, the description carries the full behavioral burden. It usefully discloses constraints (threshold range -15..+15 V, LARGe needs <= 8 channels on, active channel must be enabled), but never states that this mutates instrument state, whether changes persist or apply immediately, or any permissions needed.

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?

Dense but appropriately sized for 10 parameters, and the resource scope is front-loaded. The semicolon-chained layout is a bit cramped and cryptic in places (e.g., 'SMALl|MEDium|LARGe'), but each clause carries parameter meaning.

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 explanation, and most parameter semantics are covered. Yet for a 10-parameter mutation tool with zero annotations and zero schema descriptions, the absence of any when-to-use framing and the unexplained 'enable' parameter leave gaps.

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

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

Schema coverage is 0%, so the description must compensate, and it does so for nearly every parameter with meaning and format hints ('D3', D0D15|D15D0, SMALl|MEDium|LARGe, pod groups 1/2, global threshold fallback). It leaves the standalone 'enable' parameter unexplained and does not clarify its relation to channel_enable.

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

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

The description names the resource (logic analyzer digital channels D0..D15) and the configurable aspects (enable, label, threshold, pod, display), so an agent understands it configures LA digital channels. However, it opens with a topic fragment rather than a verb-led purpose statement and never distinguishes itself from the read-side sibling get_la_config.

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 when-to-use guidance and no mention of the alternative get_la_config for reading current LA settings. The description only describes parameter interactions (e.g., 'with a digital_channel the group is derived from it'), which is conditional semantics rather than usage 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 behavioral burden. It usefully discloses side effects and preconditions: a disabled source channel is enabled automatically, the test must be enabled before running, create_from_source requires enabled and stopped state, and output_enable pulses the rear-panel AUX OUT connector on mask events. It still omits some behaviors, such as persistence and what happens to existing mask settings, but it is substantially informative.

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

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

The description is compact and front-loads the high-level label, then uses a clean parameter list. Almost every line earns its place by supplying schema-absent semantics. It could be slightly better structured with an explicit tool verb and a short usage sentence, but it is efficient overall.

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 tool with no annotations and 0% schema description coverage, the description covers most parameters and several important preconditions and side effects. However, it lacks any description for the enable parameter and gives no sibling routing to distinguish it from get_mask_config, get_mask_result, or mask save/load tools. The presence of an output schema means return values need not be explained, but the usage and one parameter gap keep completeness only 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%, so the description must compensate and it largely does: it documents 9 of the 10 parameters, including enum values for source, operate, and output_event, and numeric ranges for x_adjust, y_adjust, and output_pulse_s. The notable omission is the enable parameter, which appears in the schema but is not described as an argument. Because of that gap, it falls short of a perfect score.

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

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

The description labels the tool as a 'Pass/fail mask test' and then lists parameters, which implies configuration, but it never explicitly says it configures or sets mask test settings. It also does not distinguish itself from sibling tools like get_mask_config or get_mask_result. The parameter list gives enough context to infer purpose, but the prose itself is vague.

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 includes preconditions for particular parameters, such as enabling the test before running it and enabling/stopping before create_from_source. However, it gives no overall guidance on when to use configure_mask versus get_mask_config, get_mask_result, save_mask_on_instrument, or load_mask_on_instrument. The agent must infer usage from sibling names.

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

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

With no annotations, the description carries full burden and delivers two important behavioral traits: partial updates leave other parameters untouched, and all validation occurs before anything is sent (no partial writes). It does not cover persistence, connection requirements, or error behavior, but the disclosed traits are substantive.

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-loaded with the scope sentence, then organized as a parameter glossary. It is long, but for 42 parameters at 0% schema coverage the density is justified and nearly every line carries constraint information. Minor redundancy in restating operator applicability.

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 explanation. For a 42-parameter mutation tool with zero schema description coverage and no annotations, the description supplies the enum values, ranges, dependencies, and passthrough rules an agent needs 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?

Schema coverage is 0% for 42 parameters, so the description must compensate fully, and it does: it enumerates allowed enums (ADD|SUBTract|...), ranges (fft_avg_count 2..1000, fft_hscale_hz 10 Hz..2 GHz), cross-field constraints (end must exceed start by >10 Hz, W1 < W2), conditional applicability (invert not for FFT/logic, fft_avg_count only in AVERage mode), and the passthrough semantics of 'extra'.

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 ('Configure math channel MATH1..MATH4') and scopes it to the manual section. It clearly conveys what the tool does, though it does not explicitly contrast itself with related siblings like get_math_config or configure_reference.

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 notes partial-update semantics ('Only given parameters are changed') and validation ordering, which guides invocation, but gives no explicit when-to-use/when-not guidance or alternatives (e.g., get_math_config for reads, configure_reference for ref channels). Usage is only implied.

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

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

With no annotations, the description must disclose behavioral traits. It notes that AMPMethod enables the tree, which is a useful dependency, but it does not state that this is a mutation, what instrument state changes, permissions, persistence, or 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?

The definition is short and front-loads the purpose before parameter details. The fragmentary first sentence and compact semicolon-separated list are efficient, though not polished.

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

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

The description covers purpose and parameter values, and an output schema exists for return values. However, for a configuration tool it omits usage context and behavioral effects, leaving the agent unable to judge when or why to call it beyond setting parameter values.

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

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

Schema description coverage is 0%, so the description must compensate. It does: it explains each of the four optional parameters and lists valid values (THReshold/RANGe/AMPMethod, AUTO/MANual, HISTogram/MAXMin), adding substantial meaning beyond the bare string 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 states a specific resource, the amplitude measurement method, and anchors it to the SCPI :MEASure:AMP tree. It does not explicitly name or contrast with sibling measurement-configuration tools, so sibling differentiation is absent.

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, prerequisites, or alternatives are provided. It explains parameter choices but not the context in which this tool should be selected over configure_measure_setup or other measure tools.

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

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

With no annotations, the description carries the full burden. It adds some behavioral context (ZOOM requires delayed sweep, link_cursors ties cursors, references SCPI command) but omits side effects, persistence, and interaction with other measurement settings.

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 front-loaded with the tool's purpose, then uses a compact list for parameters. Every line earns its place with no filler.

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

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

An output schema exists, so return values are not needed. However, for a configuration tool with no annotations, the description lacks broader usage context and behavioral details beyond parameter semantics, leaving gaps.

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

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

Schema coverage is 0%, so the description must compensate. It does so thoroughly by defining allowed values and semantics for area, type, cursor_ax, cursor_bx, and link_cursors, including units and the condition 'for area=CURSor'.

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 configures the measurement range (gating region), a specific resource. It does not explicitly differentiate from siblings like configure_measure_setup or set_cursor, but the purpose 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?

The description lists parameter options and their meanings, but provides no guidance on when to use this tool versus alternatives, nor any exclusions or prerequisites beyond the note that ZOOM 'needs delayed sweep'.

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 full behavioral disclosure. It usefully notes that delete_items clears all enabled measurement items (the destructive effect and SCPI command :MEASure:DELete), but omits whether settings persist, what instrument state is required, or what happens on default invocation.

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-loaded with a short purpose line followed by a compact per-parameter list; every line earns its place. The list form is easy to scan and wastes no 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?

An output schema exists so return values need not be explained, and parameters are well covered. However, as a mutation-config tool with no annotations, it lacks usage context, prerequisites, and sibling differentiation, leaving gaps for correct invocation decisions.

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

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

Schema description coverage is 0%, so the description must compensate, and it does: it documents all five parameters, including valid source values (CH1..CH4 / MATH1..4 / D0..D15), OFF semantics, boolean meaning for indicator, and category codes 0/1/2. Only minor formatting detail is lacking.

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 opening 'General measurement configuration' states a verb+resource, and the parameter enumeration clarifies what is configured (source, all-measure source, indicator, category, deletion). It is reasonably clear but does not distinguish itself from measurement siblings like set_measure_statistics, measure_item, or set_measure_sources_ab.

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 guidance, no prerequisite/state requirements, and no mention of alternatives among the many measure-related siblings. The agent is left to infer purpose purely from the parameter list.

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

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

With no annotations, the description carries the full burden and does so well: it discloses the runtime rejection of mode changes, the stop_first workaround sending :STOP, the FRAMe requirement of recorded frames, and that FRAMe is an undocumented firmware-observed alias. It omits any statement about side effects on acquisition state or reversibility, but the operational behavior is unusually well disclosed.

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?

Per-parameter structure with the purpose front-loaded in the first sentence makes it scannable, and every line carries information. Parenthetical asides about firmware versions and compatibility are useful but slightly bloat the lines.

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 covers six of seven parameters plus the key runtime constraint. The undefined 'enable' parameter and the unaddressed relationship to navigate_to_event are the remaining holes in an otherwise complete definition.

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 all seven parameters are bare, so the description must compensate; it documents mode, time_speed (with the raw-number passthrough), frame_speed, time_play, goto (with accepted value formats like 'TIME:STARt' and 'time_next'), and stop_first. Only 'enable' is left undefined, which is a modest gap in an otherwise strong 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?

The description opens with a concrete verb-plus-resource statement ('Navigation (time or search navigation) for waveform review') and enumerates the specific settings it controls. It is clearly distinguishable from read-side siblings like get_navigate_config, but it never acknowledges the likely overlap with navigate_to_event, which also performs navigation jumps.

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 supplies one real prerequisite rule — the instrument rejects mode changes while running, so set stop_first=True (and FRAMe needs recorded frames) — which is genuinely actionable. However, it gives no guidance on when to use this versus navigate_to_event, configure_search, or get_navigate_config, leaving the agent to infer the boundary.

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 only lists accepted values and never says what the configuration changes, whether it persists across power cycles, whether it requires remote-control mode, or when the change takes effect — all important 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?

Front-loaded with the disambiguating clause, then a compact one-line enumeration of values. Every line is functional; the layout is dense but readable and 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?

An output schema exists, so return values need not be explained, and the value domain is fully documented. For a mutation tool with zero annotations, however, the description leaves unstated the persistence, scope, and remote-control prerequisites of the change — a meaningful omission.

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 defines the parameter only as an untyped string, so the description does the entire job: it enumerates all seven operations with their expansions plus accepted short forms. It does not state what happens if 'operation' is omitted (default null), which is the one remaining 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 (configure) and resource (the QUICK button operation) and explicitly contrasts itself with the sibling measure_quick. An agent can distinguish this from measure_quick without opening either 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?

The parenthetical gives a clear when-not condition and names the correct alternative (measure_quick). It does not address adjacent save-related siblings (configure_save, save_setup), but the primary ambiguity is resolved explicitly.

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

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

With no annotations, the description carries the full burden and does so well: it discloses valid ranges (10 ns .. 1 s; 1 ms .. 1 s), the enum options for mode/direction/step, and error behavior (unknown keywords raise ValueError). It stops short of stating whether this is a persistent write, connection requirements, or interaction effects on other subsystems.

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 purpose, then uses clear 'Recording:' / 'Playback:' labels with compact clause-style parameter notes. Given 16 undocumented parameters, every sentence is load-bearing and the structure is easy to scan.

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

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

An output schema exists so return values need no explanation, and the description covers the operations, value domains, and error behavior for a 16-parameter, zero-coverage schema. The undocumented 'enable' parameter and absence of when-to-use context are the only notable omissions.

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

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

Schema description coverage is 0%, so the description must compensate, and it documents nearly all 16 parameters with value options and ranges (operate RUN|STOP, frames_max semantics, playback_mode REPeat|SINGle, etc.). Only 'enable' is left undocumented, a minor gap against otherwise thorough 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?

States a concrete verb-plus-resource ('Waveform recorder and playback') and then enumerates the exact recording and playback operations it controls. An agent can distinguish it from sibling configurators like configure_search or configure_la from the description alone.

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 details the parameters and their operations but never states when to reach for this tool versus alternatives such as get_record_status or other configure_* siblings, nor any prerequisites (e.g. connection state). Usage is implied by the recording/playback split rather than explicitly guided.

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 and does so well: it discloses prerequisites (enabled source, saved waveform before scale/offset is meaningful), the side effect of save_current (:REFerence:CURRent + :REFerence:SAVE), and that reset restores default scale/offset. It omits any return/acknowledgement behavior, but that is covered by the output schema.

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 definition is dense but front-loads the resource and resource-domain first, then groups per-parameter semantics, then the save_current/reset behaviors. The parenthetical '(manual 3.20)' and some restatement of enum options are minor overhead, but no 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?

For a 9-parameter configure call with an output schema present, the description supplies the missing pieces: prerequisites, global-vs-per-slot semantics for label_enable, and the negative guidance about file save/load in the :REFerence subsystem. Nothing an agent needs to invoke it correctly is absent.

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 there are 9 parameters, so the description must compensate — and it does: ref maps to slots REF1..REF10, source lists valid values D0..D15/CH1..CH4/MATH1..MATH4 with an enablement caveat, color enumerates GRAY/GREen/BLUE/RED/ORANge, vscale/voffset get units and range dependencies, and label_enable is clarified as a global flag. Every parameter carries meaning beyond the bare schema.

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

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

The description states the exact resource ('Reference waveform REF1..REF10') and enumerates the manipulable attributes (source, vscale/voffset, color, label, save_current, reset), so an agent knows this configures reference trace slots. It does not explicitly name the counterpart getter (get_reference_config) to sharpen the boundary, but the verb/resource pairing 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?

It gives real selection conditions: source 'must currently be enabled', vscale/voffset only work 'once a waveform has been saved into the slot', and it explicitly routes export-to-disk to get_waveform instead. It stops short of stating when NOT to use this tool versus get_reference_config, which keeps it from 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?

With no annotations, the description carries the full behavioral burden, yet it says nothing about whether settings apply immediately or persist, whether they affect the instrument state, or what permissions/context are needed. The one behavioral constraint offered — that 'extra' accepts only documented :SAVE keywords — is useful but narrow.

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?

Purpose is front-loaded in one line, followed by a tight parameter-by-parameter list with no filler. Every clause adds a distinct piece of 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?

An output schema exists, so return values need not be explained, and all eight parameters are covered, making the definition largely self-sufficient for invocation. What is missing is the surrounding context — whether these settings persist and how this tool relates to the save/get-save siblings — which the description does not address.

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 contains no descriptions or enums, so the description is the sole source of parameter meaning. It documents all eight parameters, including enum-like values (COLor|GRAY, PNG|BMP|JPG), a length/format constraint on prefix (max 16 chars, no extension), a pathname example, and the accepted shape of 'extra' — exactly the compensation a 0%-coverage schema requires.

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 header 'Image/file saving options' combined with the per-field docs make it clear this configures how files/images are saved on the instrument. It is a noun phrase rather than an explicit verb+resource, and it never names a sibling such as get_save_config or save_image_on_instrument, so an agent gets the purpose but no routing signal.

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 use this versus get_save_config, get_save_status, save_image_on_instrument, or save_waveform_on_instrument. No prerequisites or ordering (e.g. must it precede a save call?) are given, leaving the agent to infer usage entirely.

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 and does well: it documents accepted value domains, physical ranges (800 ps .. 10 s), the extra-keyword escape hatch with an example, and the failure mode ('unknown keywords raise ValueError'). It does not mention whether an existing search configuration is overwritten or whether errors surface elsewhere, so a 4 rather than 5.

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-loaded with the one-line purpose, then mode options, then per-mode parameter groups. Sentences are dense but each carries concrete information. Slightly terse fragment style with some abbreviations, but no wasted text.

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 12-parameter configuration tool with no annotations and no schema descriptions, the description supplies the value domains, units, ranges and the extra mechanism an agent needs. An output schema exists, so return values need not be explained. The omission of enable and of any interaction with an existing search config are the only real gaps.

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

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

Schema description coverage is 0%, so the description must compensate for all 12 parameters. It successfully documents mode, the edge_* and pulse_* families with allowed values and units, plus the semantics of extra. It covers most but not all parameters (e.g. enable is never mentioned), so it is strong but not complete.

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

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

States a specific verb and resource: configuring event search on the acquired waveform, with a manual reference (3.22). It enumerates exactly which search types are supported and what parameters each takes. Sibling tools like get_search_config, get_search_event_time and navigate_to_event exist, but the description doesn't explicitly name them as alternatives, 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?

It explains what each mode does and constrains documented choices ('only these two search types are documented'), which implies when to pick EDGE vs PULSe. But it never states when to call this tool versus get_search_config or navigate_to_event, nor any prerequisite that a waveform must be acquired first. 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?

With no annotations, the description carries the full behavioral burden. It only describes parameter constraints and the meaning of autoconnect; it does not disclose side effects, persistence, required permissions, or how it interacts with existing SMB configuration.

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 front-loaded and efficient, using a short opening sentence followed by structured parameter notes separated by semicolons. No verbose filler, though it could be slightly more complete without losing brevity.

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 a configuration mutation with no annotations, but an output schema exists so return values need not be explained. Parameter semantics are covered well, yet usage context and behavioral effects are missing, leaving the description only partially complete for safe invocation.

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

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

Schema description coverage is 0%, so the description must compensate. It explains all four parameters: server_path format with an example, username/password character restrictions, and what autoconnect does. This adds meaningful semantics beyond the bare schema.

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

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

The description states a specific verb and resource: 'Configure SMB (Windows share) file saving.' This distinguishes it from general save tools, but it does not differentiate from SMB-related siblings like smb_connect, smb_disconnect, or get_smb_config.

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

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

No guidance is provided on when to use this tool versus alternatives such as smb_connect or configure_save. It also omits prerequisites, such as whether a connection must already exist or whether it modifies existing settings.

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 mentions a default resource fallback but omits whether the connection is persistent, what happens on failure, whether reconnection is needed, or how it relates to the sibling 'disconnect' and 'list_resources'. Significant gaps for a state-establishing 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?

Terse and front-loaded: the action sentence comes first, then the default behavior, then an example. No filler, though the example could be integrated more cleanly.

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 connection-establishment tool with no annotations, no output schema, and 0% schema description coverage, the description should say more about lifecycle (persistence, failure behavior, relation to disconnect). What's present is helpful but incomplete.

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 explain the default resolution order (MHO98_RESOURCE env then built-in TCPIP default) and supplies a concrete USB VISA example, which is genuinely useful. However it doesn't document expected VISA resource-string syntax beyond the example or other transports.

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 (Connect) and resource (the oscilloscope), and the sibling list confirms 'disconnect' as its opposite. It doesn't explicitly differentiate itself from other connection-adjacent siblings like smb_connect, but the scope is clear.

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

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

No statement of when to call this versus alternatives, no mention that it should precede other SCPI operations, and no guidance on prerequisites. Only the resource-string format is explained.

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 required state, side effects, reversibility, or what happens if no connection exists. 'Close' implies termination but lacks depth.

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?

Single sentence with no wasted words, front-loaded. Appropriate size for a simple action.

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 0-parameter tool, the description suffices to invoke the action. However, with no annotations and no output schema, it should include more context about prerequisites and effects to be fully complete.

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

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

Zero parameters, so the schema provides no additional semantics. Baseline for 0 params 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?

States a specific verb 'Close' and resource 'current instrument connection,' making the action unambiguous. However, it does not explicitly name or differentiate from siblings like connect or smb_disconnect, though the phrase 'instrument connection' implies a VISA session rather than SMB.

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

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

No guidance on when to use this tool versus alternatives. Does not mention prerequisites (e.g., must be connected) or reference the sibling connect tool.

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

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

No annotations exist, so the description carries the full behavioral burden, and it leaves major gaps: no mention of file overwrite behavior, error handling when no USB is present, or permissions. The 'on the INSTRUMENT's own storage' note is useful but the only real disclosure.

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 with the core action and destination front-loaded, followed by a helpful example. Nothing is wasted, though it is terse enough to omit needed context.

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 format need not be described. However, for a 2-required-param tool with 0% schema coverage and no annotations, the omission of any 'bus' guidance and any usage context leaves it only marginally 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%, so the description must compensate. It clarifies the 'path' semantics well via concrete examples ('C:/123.csv', 'E:/decode.csv'), but the required 'bus' integer parameter receives no explanation at all — an agent cannot tell whether it is a bus index, a bus number, or something else.

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 (export) and resource (event table) with a clear destination (CSV on the instrument's own storage/USB stick). It distinguishes itself from host-side exports by emphasizing 'INSTRUMENT's own storage,' but never names the sibling it competes with (e.g., export_waveform_csv or the save_*_on_instrument family).

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 conveys what happens but no when-to-use guidance or exclusions. With siblings like export_waveform_csv and save_waveform_on_instrument, an agent has no basis for choosing this tool over them beyond the resource noun.

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 flag a genuinely important side effect ('stops the instrument'), which is real value beyond the schema, but it omits where the file is written, permissions/access needs, and typical runtime or size implications of a full-memory export.

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 caveat about stopping the instrument is placed where it will be read. It is arguably too terse, 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?

With 5 undocumented parameters, no annotations, and a non-obvious side effect, the description leaves too much for the agent to infer. The output schema covers return values, but parameter meaning and file-destination behavior are absent.

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% across 5 parameters, so the description must compensate. It adds essentially nothing about mode, source, start/stop, or filename; only 'full-memory' loosely hints at the range arguments. The other parameters (mode RAW, source CH1, filename) are unexplained 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?

States a specific verb+resource (CSV export of waveform data) and a scope qualifier ('full-memory'), which separates it from siblings like save_waveform_on_instrument and get_waveform. It does not explicitly say whether the CSV lands on the host or the instrument, leaving mild ambiguity against those siblings.

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

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

No statement of when to use this versus save_waveform_on_instrument, get_waveform, or save_memory_waveform_on_instrument. The 'full-memory' qualifier implies a use case, but nothing tells the agent when this is the wrong 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. 'Read back' implies a non-mutating read, which is useful, but it does not explicitly confirm read-only safety, permissions, or side effects. For a simple getter this is adequate but not rich.

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, efficiently structured sentence with no wasted words. The core action and scope are front-loaded, and the additional sample-rate detail is appropriately brief.

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

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

Given the low complexity, zero input parameters, and the presence of an output schema, the description provides enough context for correct invocation. It does not need to explain return values because the output schema covers that.

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 per the scoring rules. The description adds the useful note that the returned settings include the current sample rate, but there are no input parameters to clarify.

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 ('Read back') and a precise resource ('acquisition settings'), and the phrase 'incl. current sample rate' clarifies scope further. It clearly contrasts with the sibling set_acquire by verb, so an agent can distinguish a read from a write without opening the 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?

The description states what the tool does but gives no guidance on when to use it versus alternatives such as set_acquire, get_timebase, or get_channel. There is no explicit context, prerequisite, or exclusion to help an agent choose it correctly.

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 clarify the operation is a non-mutating read and that all returned values are binary (0 or 1), but says nothing about permissions, side effects, or rate/scope 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?

One short sentence, front-loaded with the verb and resource, and the only qualifier (binary return values) is appended compactly. No wasted text.

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 structure needn't be explained, and there are no parameters to document. It is nearly complete, though it never enumerates which autoset options exist or what each flag controls.

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?

Zero parameters, so there is no parameter semantics to document; baseline 4 applies. The parenthetical 'all return 0 or 1' adds value-domain context but is really a return-value note.

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: 'Read back the AUTO (autoset) option states'. Clear read-only getter, and the naming pairs obviously with the sibling set_autoset_options. No explicit sibling mention, 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?

No when-to-use or when-not-to-use guidance. The only implicit signal is that 'read back' contrasts with the set_autoset_options sibling, but the description never names it or states conditions 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.

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 return format ('raw SCPI strings') and enumerates the covered settings (output state, function, frequency, amplitude, offset, phase, impedance), which is genuine behavioral context. However it says nothing about channel range validation, whether the AWG must be enabled, or any error behavior for an invalid 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 sentences, front-loaded with purpose, followed by a scoping/alternative clause. Nothing is redundant and the sizing matches the complexity of the 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?

An output schema exists, so return values need not be explained, and the description covers scope and the sibling alternative adequately. The only real gap is the undocumented channel parameter, which leaves a minor hole for a tool whose sole input is that 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% and there is a single required parameter ('channel') that the description never mentions. It does not say what channel values are valid or how the channel number maps to the instrument's :SOURce<n> numbering, 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 states a specific verb and resource ('Read back the core generator channel configuration') and immediately delimits scope with the parenthetical '(raw SCPI strings)'. It also names the exact sibling (get_awg_full_config) that covers the complementary superset, so the agent can distinguish the two without opening either 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?

It explicitly routes the agent: use get_awg_full_config() when you need every :SOURce<n> readback such as period, high/low levels, duty, symmetry, arb path and modulation. That is a clear when-to-use-this-vs-alternative statement. It stops short of stating prerequisites or failure conditions, so it is not a full 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?

With no annotations, the description carries the full burden. It discloses the return semantics well (booleans for states, floats with units, enum short-forms like 'SQU'/'TRI', the arbitrary waveform path and AM/FM/PM modulation config), but says nothing about error behavior, invalid channels, or permissions for this read.

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-loaded with the core action, then return-value detail. Two tight paragraphs with little waste, though the manual-section citation and enum examples add length without aiding invocation.

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 explaining return values is not strictly required, and the description does so anyway. However, it omits any channel-parameter meaning and sibling differentiation, leaving the invocation context incomplete for a 1-param 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?

Schema coverage is 0% – the single 'channel' parameter has no description. The description never mentions the channel argument at all, so it fails to compensate for the schema gap by explaining valid ranges or which channel is targeted.

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 ('Read back every generator channel setting') and cites the manual section (3.25.1 - 3.25.25), making the scope concrete. It does not explicitly distinguish itself from the sibling get_awg_config, so the 'full' vs. standard read distinction is only implied.

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 is given. The description never names the alternative get_awg_config or explains when to prefer this comprehensive read over the lighter one, leaving the agent to infer the difference from the tool 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 provided, the description carries the full burden. It discloses that values are 'engineered' (booleans, floats in Hz/V, int points per decade) and that ref_in/ref_out come back in short form (CHAN1..4). This is meaningful behavioral context about return value formatting. It doesn't, however, describe side effects or whether reading changes state.

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

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

The description is reasonably short and front-loaded with the purpose. However, the parenthetical manual reference and the parenthetical form note interrupt flow, and the second sentence mixes parameter explanation with return-value explanation.

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-value format need not be fully explained. The description covers the parameter and some return formatting. But with 0% schema coverage for the parameter and no annotations, more context on the parameter's effect and any usage constraints would be expected.

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 explain voltage_range selects the frequency range for :BODeplot:VOLTage? and lists the enum-like values, which is helpful. However, the schema shows anyOf string/integer/number with a default, and the description's numeric forms note is vague. The description adds only partial meaning for the single 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 (read back) and a specific resource (the full Bode plot configuration), with a manual section reference. The sibling set has get_bode_config, get_awg_config, etc., and this clearly identifies its scope as the complete Bode 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?

The description implies usage (read the full configuration) but doesn't state when to use this versus a hypothetical set_bode_config or other configuration-read tools. No explicit alternatives or exclusions are provided.

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

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

With no annotations, the description carries the full burden and does so well: it discloses which SCPI queries fire, that per-protocol keywords land under 'protocol_config' keyed by keyword (e.g. 'RS232:BAUD'), and that thresholds return {type: volts string}. It omits failure modes (invalid bus index, protocol mismatch) and any note on cost/latency of the full=True path.

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-loaded with the one-line purpose, then organized into default-vs-optional-argument behavior and a short glossary for protocol/thresholds. Dense with SCPI jargon but nearly every clause carries information; the indented parameter notes are slightly redundant with the body.

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 shape needn't be fully re-specified, yet the description still names the notable keys. For a 4-parameter readback tool with no annotations, this is close to complete; only error/edge-case behavior 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 0%, so the description must compensate, and it largely does: full, protocol and thresholds all get behavioral semantics beyond their names. The required 'bus' parameter is only indirectly explained via the ':BUS<n>:' notation, leaving valid-index range 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 ('Read back the decoding bus configuration') and immediately scopes it by listing the exact SCPI queries issued. It does not explicitly name the write-side counterpart (configure_bus) or read_bus_data, so sibling differentiation is left to inference, but the purpose itself 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 conditional guidance: default invocation returns only MODE?/DISPlay?/LABel?, while full=True / protocol= / thresholds= each unlock additional query groups. It stops short of saying when to prefer this tool over alternatives such as read_bus_data or raw scpi.

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 only says 'read back configuration', omitting the essential context that this is a read-only operation, what happens on an invalid channel number, and how it differs from get_channel_full. An output schema exists, so return values need not be explained, but the tool's scope and safety profile are not disclosed.

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 efficient sentence with the object of the operation front-loaded. It is appropriately brief, though the brevity here is partly under-specification rather than purely good conciseness.

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 in a large family of near-identical getters with no annotations and 0% parameter coverage, a one-sentence description is insufficient. It fails to clarify scope relative to get_channel_full or explain the required channel argument, leaving important gaps.

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

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

Schema description coverage is 0% and the single 'channel' parameter has no description in either the schema or the description text. The description does not indicate what the channel argument is (index, range, valid values), so it fails to 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 back) and resource (configuration of an analog channel). This is clearer than many siblings, but it doesn't distinguish itself from the very similar 'get_channel_full' sibling, nor from 'set_channel' / 'get_trigger_config', leaving the agent to infer the scope difference.

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 at all. Crucially, the description gives no way to choose between this tool and 'get_channel_full', which reads similarly. The agent is left to guess which retrieval variant to call.

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. 'Read back' implies a safe, non-mutating operation and it names the specific extra fields returned (vernier, TCALibrate in s, label visibility), but it does not cover any permission, timing, or side-effect considerations.

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, front-loaded sentences with no filler; the core purpose leads and the differential detail follows. Efficient, though the reference to internal names adds little standalone 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 no explanation, and the description adequately conveys what is read. However, the undocumented channel parameter leaves a genuine gap for a tool whose only input must be supplied correctly.

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

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

Schema description coverage is 0% and the single parameter 'channel' is undocumented in both schema and description. The description does not clarify the accepted channel range, numbering scheme, or indexing, so it fails to 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 and resource ('read back the complete configuration of an analog channel') and explicitly positions it against the sibling get_channel() by naming the extra fields it adds. An agent can distinguish this from get_channel without opening either 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?

The phrase 'Adds ... queries to get_channel()' gives clear context that this is the fuller variant to use when the vernier, delay calibration, or label visibility fields are needed, implying get_channel() is the lighter alternative. It stops short of an explicit when-not rule, but the routing 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?

With no annotations provided, the description carries the full behavioral burden and does so well: it explains what is always returned in manual mode, that track=True adds track-mode readings and the track axis, and that unavailable readings become '<error ...>' strings. It stops short of covering prerequisite states (e.g., whether a cursor mode must already be active), so it is strong but not exhaustive.

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 purpose and then progressively detailing mode behavior, parameter effect, and error format. Every sentence adds needed information without redundancy.

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

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

For a simple one-parameter read tool whose output schema already documents the return keys, the description supplies the remaining context: what is always returned, what track=True adds, and how unavailable readings are represented. Nothing essential 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 0%, so the description must compensate for the single undocumented parameter. It does exactly that by explaining that track=True additionally reads track-mode readings (track_* keys) and the track axis, which is meaning beyond the schema's bare boolean default.

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 (cursor positions and deltas) scoped to the active cursor mode. However, it does not distinguish itself from the sibling tool get_cursor_xy_values, leaving an agent to infer which cursor-reading tool is appropriate.

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 by referencing the active cursor mode, but gives no explicit when-to-use or when-not-to-use guidance, nor does it name an alternative tool. An agent gets context but must infer the right situation.

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

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

With no annotations, the description carries the full burden and does a reasonable job: it declares the unit (V), the required instrument state, and the failure behavior (unavailable readings returned as '<error ...>' strings). It does not cover permissions or returned structure, but the output schema handles the latter.

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, front-loaded with the action and result, followed by the necessary precondition and error note. No filler; every clause adds 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 zero-parameter read tool with an output schema, the description supplies the essential context an agent needs: the required XY-mode state and the error-string convention. It is largely complete, though a pointer to the time-domain sibling would close the remaining 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 takes zero parameters, so the baseline is 4. There is nothing for the description to disambiguate, and it correctly adds no parameter noise.

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 XY-mode cursor positions and deltas') with units (V), which is far more than a restatement of the name. The 'XY-mode' qualifier implicitly separates it from the sibling get_cursor_values, but no sibling is explicitly named, so it stops short of full 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?

Gives a clear precondition: it is only meaningful with :CURSor:MODE XY and the timebase in XY mode. This tells the agent when the tool is applicable, but it never names the alternative (get_cursor_values) for time-domain cursors or states 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?

With no annotations, the description carries the full burden, and it partially meets it: 'Read' implies a non-destructive, side-effect-free query and it documents the returned date/time formats. However, it says nothing about connection requirements, failure behavior, or whether the clock reflects instrument-local time, which matters for an instrument-control 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 naming the action, the underlying queries and the return formats, with no filler. Every clause adds information an agent can act on.

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 with an output schema present, the description is essentially complete about what is returned; the output schema covers the structured return values. Only minor operational context (connection/latency expectations) is absent, which is acceptable at this complexity.

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 of 4 applies; there is nothing for the description to clarify beyond confirming it is a no-argument read.

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'), a specific resource (the instrument clock) and even the underlying SCPI queries (:SYSTem:DATE?/:SYSTem:TIME?), so the operation is unambiguous. It does not explicitly name the complementary sibling (set_datetime), but the read/write distinction is evident from the tool name alone.

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 set_datetime, get_system_info or get_system_config. Usage is only weakly implied by the verb 'Read'; there are no exclusions or prerequisites 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 full behavioral burden. It does state 'Read back,' which discloses the read-only, side-effect-free nature, and lists the returned settings. It does not mention permissions, rate limits, or any edge behavior, but for a simple getter this is adequate.

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 one sentence, then gives a compact enumeration of the settings. No filler, though the field list is somewhat detailed for a description whose return values are already covered by the output schema.

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

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

For a zero-parameter getter with an output schema, the description adequately covers purpose and scope. The output schema handles return values, so the description needn't explain them, though its enumeration is helpful redundancy. Lacks only usage context.

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

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

The tool takes zero parameters, which sets the baseline at 4. The description's enumeration of returned fields is about outputs, not inputs, so it does 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+resource ('Read back the display settings') and enumerates the exact settings returned, making the scope precise. The read-vs-set distinction from its sibling set_display is inherent in the verb, so an agent can tell them apart 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?

No guidance on when to call this versus alternatives, nor any prerequisites or exclusions. Usage is only implicitly obvious from the name and the sibling set_display.

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 queue-read semantics and the 20-entry cap, but omits the critical fact that the schema's `clear` parameter defaults to true, meaning a plain call silently clears the queue it just read. That destructive-by-default behavior is exactly what an agent must 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 short sentences, front-loaded with the action and resource, with no filler. Nothing here is wasted text.

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 for a tool whose unsurfaced default argument wipes the error queue, the description should at minimum warn about the clearing behavior and note when to use it versus the other status tools. Those omissions make it incomplete for correct invocation.

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

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

Schema description coverage is 0% and the single `clear` boolean parameter is never mentioned in the description. Since `clear` defaults to true and changes whether the queue is wiped, the description's silence on it is a real gap rather than harmless brevity.

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 instrument error queue') and even pins the exact SCPI query (:SYSTem:ERRor?), so an agent knows precisely what this does. It is distinguishable from siblings like get_status, get_ieee488_status, and clear_status, which target different status registers/queues.

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 by the tool name and the error-queue semantics (poll after sending commands), but the description never states when to prefer this over get_status, get_ieee488_status, or clear_status, nor when a read is appropriate. No alternatives are named.

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. 'Read back' implies a non-destructive read, which is useful, but it says nothing about permissions, side effects, or rate behavior. The manual section reference is opaque to an agent.

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?

It is a single short sentence with no filler, and the action is front-loaded. The parenthetical '(manual 3.11.1-3.11.8)' is noise for an agent that cannot consult a document, slightly diluting the value of the brevity.

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 explanation, and with zero parameters the schema is trivially covered. The description is adequate for a simple read-only getter but adds no operational context an agent might want.

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 for the description to document and the baseline is 4. No parameter meaning is missing or misrepresented.

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 ('Read back') and resource ('histogram configuration'), so an agent knows this is the getter counterpart to set_histogram. However, it does not explicitly distinguish itself from siblings like read_histogram_stats or set_histogram, which matters in a large sibling set.

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 guidance, no mention of prerequisites, and no explicit routing to alternatives such as set_histogram for writing or read_histogram_stats for statistics. The read semantics are implied only by the word 'Read'.

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