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

Annotations declare destructiveHint=true, and the description explains what gets destroyed: it replaces the user's setup. It also notes that the setup is backed up first and describes the return value (backup path and new settings), adding significant value beyond annotations.

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

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

Three sentences, front-loaded with purpose, followed by the destructive action and the return value. No unnecessary content.

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 annotations covering safety, the description is complete: it states what it does, warns about replacement, mentions backup, and lists returns. No output schema exists, so including return info is beneficial.

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 baseline is 4. The description does not need to explain parameters.

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

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

The description uses a specific verb and resource: it configures scales, timebase, and trigger settings for connected signals, analogous to pressing the AUTO key. This distinguishes it from configuration siblings like configure_channel or configure_timebase.

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

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

The description implies the tool automates setup like an AUTO key, but it does not explicitly state when to use it vs manual configuration tools, nor when not to. Implicit usage only.

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

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

Annotations already declare destructiveHint=true, readOnlyHint=false, and idempotentHint=false, so the safety profile is covered structurally. The description adds real context beyond that by warning that user-added items are also destroyed, which is not derivable from the annotations. It stops short of stating irreversibility or any confirmation requirement.

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

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

Two sentences, front-loaded with the operation and its modes. The trailing sentence about user-added items is short and earns its place as a behavioral warning, though the sentence is split awkwardly mid-clause by the parenthetical.

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

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

With no output schema, one optional parameter, and annotations covering the safety profile, the description supplies what is missing: parameter domain, default behavior, and the scope of destruction. It could still mention out-of-range handling, but nothing essential for correct invocation 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 description coverage is 0% and the parameter is an undocumented integer with a null default, so the description carries the full burden. It fully specifies the domain: item is 1-5, ordered left to right, and null/omitted means all items.

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 (remove) and resource (items from the measurement bar), including its physical location on the scope screen. An agent can distinguish this from siblings like measure, screenshot, or reset 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?

Explains the two invocation modes clearly: pass item to remove one, or omit it to remove all by default. It does not name or compare against sibling tools, but the branching behavior of its own parameter is fully described.

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

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

Annotations already declare idempotent=true, destructive=false, readOnly=false, so safety is covered. The description adds genuinely useful context beyond that: partial-merge semantics ('only the parameters given are changed') and the return shape ('requested/before/after'). It stops short of stating auth needs or failure behavior.

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

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

Three sentences, front-loaded with the core action, then parameter constraints, then return value. Dense but each clause earns its place; the range list is the only heavy spot.

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?

Mutations with no output schema, and the description does cover return values and partial-update behavior. Still, the enum semantics and memory-depth units are missing, leaving an agent short of fully correct invocation guidance for a 3-parameter 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 carry the load. It usefully documents 'averages' (power of two, 2-1024) and the memory-depth ranges, but leaves the acquisition_type enum values (NORMAL/AVERAGES/PEAK/HRESOLUTION) and the 'AUTO' memory depth unexplained.

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

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

States a specific verb+resource ('Change how the scope acquires'), which cleanly marks the acquisition-configuration domain. It doesn't explicitly name or differentiate itself from siblings like configure_channel or configure_trigger, but the topic 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?

Conveys conditional usage well ('averages ... applies in AVERAGES mode', memory-depth limits that vary with channel count), which is real guidance. However, it never says when to reach for this tool versus alternatives such as configure_channel/timebase/trigger, nor any prerequisites.

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

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

Annotations already mark this as a non-destructive, idempotent write, so the safety profile is covered. The description adds genuinely useful behavior beyond that: only supplied parameters mutate, probe_ratio must match the probe's attenuation switch, and it rescales V/div (a non-obvious side effect), plus the requested/before/after return shape. It does not mention required device state or error behavior, keeping it short of a 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?

Three dense sentences, zero filler, front-loaded with the mutation semantics before the parameter nuances. The note about the return payload earns its place because no output schema exists.

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

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

For an 8-parameter mutation tool with no output schema, the description covers the critical unknowns: partial-update semantics, channel identifier formats, the probe_ratio constraint, and the return shape. It falls short only on documenting the remaining six parameters and any preconditions or units beyond what the parameter names imply.

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 8 parameters and it only explains two: channel (accepts 1-4 or CHAN1-CHAN4) and probe_ratio (must match attenuation, rescales V/div). The remaining six (invert, display, coupling, bw_limit, offset_v, scale_v_per_div) get no textual explanation, though their names and inline enums for coupling/bw_limit carry most of the 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 and resource ('Change one channel's settings') and immediately qualifies the semantics with 'only the parameters given are changed', which pins down partial-update behavior. This clearly separates it from sibling configure_* tools that target timebase, trigger, or acquisition rather than a channel.

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

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

The scope is implied (one channel, partial update), so an agent can infer it is the channel-settings entry point, but there is no explicit when-to-use or when-not-to-use guidance and no mention of how it relates to configure_timebase/configure_trigger/configure_acquisition or get_settings. Usage is inferable but not routed.

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 annotations already declaring mutation (readOnlyHint=false), idempotence, and non-destructiveness, the description adds genuinely useful context: only supplied parameters are changed (partial update), and it discloses the requested/before/after return shape in the absence of an output schema. It does not explain rollback or permission needs, but the added value is real.

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 core action and the partial-update constraint, followed by the return-shape disclosure. No filler and each clause carries 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 3-param, no-output-schema mutation tool with modest annotation coverage, the description supplies the return format and update semantics but leaves the meanings of 'mode' and 'scale_s_per_div' unexplained. An agent can call it, but cannot confidently choose values for two of the three parameters.

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

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

Schema description coverage is 0% for 3 parameters, so the description must compensate and largely doesn't: it explains only offset_s ('moves the trigger point') and says nothing about mode's MAIN/XY/ROLL values or scale_s_per_div's units. Two of three parameters remain semantically opaque.

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 clear verb ('Change') and resource ('horizontal settings'), which plausibly maps to timebase configuration and separates it from vertical/channel siblings. However, it never names or contrasts itself with the configure_* siblings, so an agent must infer the distinction from 'horizontal' 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?

There is no explicit when-to-use guidance, no prerequisites, and no named alternative among the many configure_* siblings. The only directional cue is the implicit partial-update behavior, which is behavioral rather than selection guidance.

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

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

Annotations cover safety (readOnly false, idempotent true, destructive false), so the bar is lower, yet the description still adds real context: partial-update semantics, the implicit mode switch to EDGE, sweep free-run vs wait behavior, and the returned requested/before/after triple. Only the SINGLE sweep mode and coupling behavior go unexplained.

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

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

Front-loaded with the core action and the most important qualifier, then dense supporting sentences with no filler. Slightly terse and telegraphed, but every clause carries 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?

No output schema exists, and the description compensates by stating the return shape (requested/before/after). Combined with the mode-switch and sweep semantics, an agent has enough to invoke it correctly, though a few parameters (coupling, holdoff_s, SINGLE) remain opaque.

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

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

Schema coverage is 0%, so the description must carry the load and it partly does: source values (1-4, CHAN1-CHAN4, AC) and sweep AUTO/NORMAL are documented, and the effect of slope/level is described. But level_v units, coupling options, holdoff_s, and the SINGLE sweep value are left undocumented in both schema and description.

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

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

States a specific verb+resource ("Change the edge-trigger settings") and immediately qualifies the update semantics as partial ("only the parameters given are changed"). This clearly separates it from siblings like configure_channel, configure_timebase, and configure_acquisition, which target different subsystems.

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 conditional behavior — supplying source/slope/level implicitly switches the trigger to EDGE mode, and it distinguishes sweep AUTO (free-run) from NORMAL (waits for trigger). However, it never says when to choose this tool over alternatives or what prerequisites/permissions apply, so 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?

Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, so the safety profile is covered. The description adds a genuinely useful behavioral detail the annotations can't: all values are SI units (volts, seconds, samples per second), which tells the agent how to interpret and compare returned numbers.

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, no filler, with the resource scope front-loaded and the unit convention as a compact second sentence that 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?

With no output schema, the description carries the burden of saying what comes back, and it does list the four settings groups plus the unit convention. It does not describe the return structure (per-channel grouping, scalar vs. structured values), which is the only remaining gap for a zero-parameter read tool.

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

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

The tool takes zero parameters, so the baseline is 4. The schema confirms an empty properties object, and the description correctly implies the call is unparameterized and returns a fixed set of settings.

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

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

Names a specific verb (get) and resource (settings) and enumerates the domains covered: channel, timebase, trigger and acquisition configuration. This makes it clearly the read counterpart to configure_channel/configure_timebase/configure_trigger/configure_acquisition, though it never names those siblings explicitly.

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

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

Usage is implied rather than stated: an agent can infer this is how you read current instrument state before deciding what to configure. There is no explicit when-to-use or when-not-to-use guidance and no mention of the configure_* alternatives, so routing must be inferred from the 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?

Annotations already cover the safety profile (readOnly, idempotent, non-destructive), so the bar is lower. The description adds valuable behavior beyond that: the trace is limited to 1200 on-screen points, a CSV file is written to disk (a real side effect), and the `clipped` flag warns that extremes are unreliable when the trace runs off screen.

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

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

Three tight sentences, each carrying distinct information (what it returns, the clipping caveat, the parameter format), front-loaded with the core action. 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?

With no output schema, the description steps in to describe the return (summary stats plus CSV path) and the units (time_s, volts). Combined with the clipping caveat, an agent has everything needed to call and interpret this tool 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 carries the full burden, and it does: it documents the accepted channel formats (1-4 or CHAN1-CHAN4). For the single required parameter this fully compensates for the schema gap.

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

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

States a specific verb and resource (read one channel's on-screen trace) with concrete scope (1200 points, CSV output, summary stats). This is clearly distinguishable from siblings like measure, screenshot, or scpi_query.

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 describing the output and the cached-trace model, but it never says when to prefer this over `measure` (numeric measurements) or `screenshot` (image capture), which are the closest alternatives. No exclusions or prerequisites are given.

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

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

Annotations already declare readOnly/idempotent/non-destructive safety. With no output schema present, the description carries the return-value burden and does so by enumerating the four identification fields returned, which is genuinely useful behavioral context for 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?

A single economical sentence with the key content front-loaded and zero filler. It reads as a fragment rather than a full sentence, but nothing is wasted.

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

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

For a simple read-only identification call with no parameters and no output schema, listing the returned fields is essentially all the agent needs. Minor gaps remain around error/no-device behavior, but the definition is adequate for the tool's 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 there is nothing for the description to disambiguate; the baseline for a no-parameter tool applies.

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 exact resource and the specific content returned (manufacturer, model, serial, firmware) for the attached scope, which lets an agent distinguish it from siblings like get_settings or get_waveform. It is a noun phrase rather than a verb+resource statement, but the purpose is unmistakable.

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

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

There is no guidance on when to call this versus alternatives such as get_settings or scpi_query, and no mention of prerequisites (e.g. scope must be connected). The agent must infer usage entirely from context.

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

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

The annotations already declare non-read-only, non-destructive, idempotent, and closed-world behavior. The description adds important context beyond those annotations: each requested item is added to the measurement bar, at most 5 are shown with older ones scrolling off, and null means the scope could not measure the item.

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 purpose, then parameter formats, then the side effect. The long item enumeration is necessary because the schema provides no parameter descriptions, and there is little filler.

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

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

With no output schema and 0% schema parameter coverage, the description supplies enough parameter vocabulary, return-null semantics, and side-effect context to use the tool correctly. It could still be more complete about the output shape and about when to prefer alternatives like scpi_query or clear_measurements.

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 carries the full burden. It fully specifies channel values (1-4 or CHAN1-CHAN4) and enumerates every accepted item abbreviation plus long forms, and it explains the meaning of a null measurement result.

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 that the tool returns the scope's automatic measurements for one channel and enumerates the measurable items. It is specific about the resource and action, but it does not explicitly distinguish itself from siblings such as clear_measurements or scpi_query.

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, prerequisites, or alternative-tool routing. The agent must infer that this is the tool for obtaining automatic measurements rather than clearing them or using a lower-level SCPI query.

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

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

The description goes beyond the annotations by disclosing that a backup is taken before the reset and that the backup path and new settings are returned. Combined with destructiveHint=true, an agent can understand the operation's safety profile. It stops short of stating whether the reset is reversible from that backup or what other state is lost.

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 operation and command, then the side effect, then the return value. Every sentence earns its place with no 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?

With no output schema, the description helpfully documents return values (backup path, new settings). Annotations cover the destructive/idempotent profile, so the definition is nearly complete for a zero-parameter mutation; only the exact scope of what is lost is unspecified.

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. The description correctly implies a no-argument operation and adds no misleading parameter information.

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 ('Reset the scope to factory defaults') and names the SCPI command (*RST), which pins down the exact operation. It is distinguishable from the sibling restore_setup, which restores a stored backup rather than factory defaults.

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 destructive factory-reset semantics, and the note that the setup is backed up first hints at safety context, but the description never says when to choose this over restore_setup or save_setup. No explicit exclusions or prerequisites are given.

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

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

Annotations already declare destructiveHint=true, idempotentHint=false and readOnlyHint=false, so the safety profile is covered. The description adds genuinely new context: the current setup is backed up before the overwrite, the operation takes about 6 seconds, and it returns the backup path plus resulting 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?

Three short sentences, zero filler, with the action and its data source front-loaded before the side effect (backup) and the latency/return notes.

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?

No output schema exists, and the description compensates by naming the return values (backup path, resulting settings); combined with the destructive annotation covered by the 'backed up first' note, an agent has everything needed to call and interpret this 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% for the single 'path' parameter, so the description must carry the burden. It only implicitly identifies the path as that of a save_setup output or compatible backup, giving no format, extension, or example — enough to infer intent but not enough to resolve ambiguity.

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 (restore) and resource (whole setup) and explicitly ties it to the sibling save_setup, so an agent can distinguish it from save_setup and reset 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?

Clarifies the applicable input scope — a setup saved by save_setup or a compatible backup from another tool — which tells the agent when this tool applies. It does not name a when-not case or a competing alternative (e.g. reset), so it falls short of a 5.

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

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

Annotations mark the tool destructive and non-idempotent; the description goes further and explains exactly why — run and single overwrite a stopped capture — plus the blocking behavior of wait_s for single. It does not cover prerequisites (e.g. required acquisition state) or failure modes, so it falls short of a 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?

Three dense sentences, front-loaded with the action summary before caveats. Every sentence adds usable information; no restatement of the name or 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?

Though there is no output schema, the description names the return values (trigger status RUN/WAIT/TD/AUTO/STOP and sweep mode), so the agent knows what to expect. Combined with the action semantics and destructive caveat, nothing critical to 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?

With 0% schema description coverage, the description must carry the parameter burden, and it largely does: each action enum value is defined, and wait_s is explained as the maximum wait for single completion. It omits the wait_s default of 0, which is only visible 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?

The description gives a specific verb set tied to the resource: start/freeze acquisition, arm a single acquisition, force a trigger. It also explains each enum value (run, stop, single, force_trigger) in plain operational terms, so the agent can distinguish this 'execute an acquisition state change' tool from the configure_* siblings that set parameters.

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 states the conditions under which each action applies, notably that run and single overwrite a stopped capture and that single blocks for wait_s. There is no explicit reference to alternatives such as configure_acquisition or configure_trigger, but the setup-versus-execute distinction is inferable from the action semantics.

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

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

Annotations declare readOnlyHint=true and destructiveHint=false, but the description says the tool writes the setup 'to a file' — a filesystem side effect that a read-only tool should not have, creating tension with the declared annotation profile. Beyond that tension, the description does convey a useful behavioral fact (the call returns a path) that annotations do not cover.

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

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

A single sentence with zero waste, front-loading the action and then the round-trip relationship. Nothing could be removed without losing routing 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 tool with no output schema, the description covers both the action and how the result is consumed (path -> restore_setup), which is what an agent needs. It does not say where the file lives or in what format, but that is minor for this level of 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?

Zero parameters, so the baseline is 4; nothing needs explaining. The description usefully notes the output is a path, which is context for how the call is used downstream by restore_setup(path).

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 ('Save the scope's whole setup to a file') and names the complementary sibling restore_setup, so an agent can distinguish it from the many configure_* / get_* siblings immediately.

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 pairs the tool with its counterpart explicitly ('restore_setup(path) brings it back'), which tells the agent when this tool is the right choice in a save/restore workflow. It stops short of stating when not to use it (e.g., vs. get_settings for inspecting values without persisting).

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

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

Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, so safety is covered; the description adds non-obvious behavior — the '?' header requirement and the fact that mutating commands are rejected rather than executed — which is genuinely useful server-side 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?

Two tight sentences; the action and its scope come first, the constraint second. Every phrase 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 no explanation, and the description covers the one parameter's format plus the rejection behavior. Nothing needed to call it correctly is missing.

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

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

Schema coverage is 0%, so the description must carry the load, and it does: it gives concrete examples (':TRIGger:STATus?', ':CHANnel1:SCALe?') and states the required header format, adding meaning well beyond a bare string 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 (send a read-only SCPI query), the constraint on the input (header must end in '?'), and the effect (return the reply). This clearly separates it from the sibling scpi_write.

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 clause 'Commands that change settings are refused' tells the agent when this tool is not appropriate and implicitly routes write operations to scpi_write, but it never names that sibling explicitly, leaving the alternative to inference.

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

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

Annotations already declare destructiveHint=true and readOnlyHint=false, so the safety profile is covered. The description adds valuable behavior beyond that: a setup backup occurs first, and the call fails when the scope reports an error. It does not explain reversibility or rate limits, but the added side-effect and failure semantics are substantial.

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 followed by the alternative and the side-effect/failure behavior. No wasted words.

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

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

For a single-parameter raw-command tool with no output schema and annotations already carrying the safety flags, the description covers purpose, alternative routing, backup, and failure behavior. Only minor gaps remain around accepted command syntax rules and return/failure detail beyond 'fails'.

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

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

There is a single parameter and schema description coverage is 0%, so the description must carry the load. It provides a concrete example command (':CHANnel1:VERNier ON') that illustrates the expected format, which meaningfully compensates for the undocumented parameter, though it doesn't state constraints such as required terminator or quoting.

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 ('Send one raw SCPI command that expects no reply') and immediately distinguishes itself from the sibling scpi_query. The example command makes the scope of 'raw command' concrete.

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 reply-expecting calls to scpi_query and positions itself as the catch-all for anything the other tools don't cover. It gives clear context but no explicit 'when not to use' beyond the query/write split.

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

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

Annotations already declare readOnly/idempotent/non-destructive, but the description adds a genuine side effect not visible in the schema: the capture is written to disk and a path is returned. That is real behavioral value beyond the structured fields, though it does not clarify permissions or failure modes.

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 clauses, front-loaded with the action and format, then the side effect and return value. No 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?

With no output schema, the description does the necessary work of saying what comes back (the file path) and the image format/resolution. Minor gap: it does not say whether image data is also returned inline or what the path format looks like.

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 nothing for the description to explain; baseline is 4. The description appropriately spends no words on nonexistent inputs.

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

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

States a specific verb and resource ('Capture the scope's screen') plus the output format and dimensions (800x480 PNG), which cleanly separates it from siblings like get_waveform or measure that return data rather than a rendered image.

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 says when to prefer a screenshot over get_waveform, measure, or other read siblings, nor does it state any preconditions. An agent must infer the choice 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.