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

With no annotations, the description carries the behavioral burden. It discloses that the tool changes settings, waits for completion, returns state, and does not retry automatically. This covers the main behavioral expectations for a zero-parameter action, though it does not mention potential failures or timeouts.

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-loaded. The first sentence states the action and its effects, and the second sentence clarifies key exclusions, with no redundant or filler 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 parameterless action with no output schema, the description covers the essential behavior: what is changed, that it waits, what it returns, and that it does not retry or reset. It could be more explicit about prerequisites or return-state details, but it is reasonably complete for this tool's simplicity.

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

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

The tool has zero parameters and the schema is empty, so there is nothing for the description to clarify. The baseline of 4 applies because no parameter documentation is needed.

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

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

The description clearly names the action (autoscale/auto-setup) and specifies what it affects: channels, timebase, and trigger. It also distinguishes itself from capability discovery and factory reset, which helps separate it from sibling tools like get_capabilities.

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 tool is for automatically configuring acquisition settings and waiting for completion, but it does not explicitly state when to choose autoscale over alternatives such as set_channel, set_timebase, or set_trigger. It provides exclusions rather than positive selection criteria.

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 behavioral burden and does so well: it discloses the read/clear side effect, the 16-entry limit, the first-only/No-error result, and the no-retries policy. It stops short of specifying exact return formatting or whether the clear always occurs.

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 entire description is one compact, front-loaded sentence with three high-value clauses: action/scope, return behavior, and retry policy. No filler or redundancy.

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

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

For a zero-parameter tool with no output schema, it specifies the input surface (none) and return behavior (first error or 'No error'), which is nearly complete. It could add the response shape or clarify whether clearing is unconditional, but the low complexity keeps the gap minor.

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

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

The tool takes zero parameters, so the schema and context signals fully cover the parameter surface. The description adds no parameter detail, but none is needed; per the rubric, 0 params earns a baseline of 4.

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

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

The description identifies a precise action ('Read/clear') tied to a specific resource ('SCPI error entries') and states the output contract (return first or 'No error'), leaving no doubt about what check_error does relative to vague sibling names like idn or get_scope_state.

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

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

Usage context is implied by the tool name and description: it is the error-checking operation among SCPI-related siblings. However, it never states when to choose this over scpi_execute or scpi_catalog, nor gives explicit exclusions.

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

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

With no annotations, the description carries the full burden and does disclose meaningful behavior: mode-dependent read locations, the prerequisite on the source, and the side-effect caveat 'Transfer settings are not restored; acquisition is unchanged.' It could add file-overwrite behavior, but it provides solid transparency for a save operation.

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

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

The description is four short sentences with no filler. The main purpose is front-loaded, and every subsequent sentence adds distinct useful information: mode behavior, source precondition, and side-effect caveat.

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

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

For a tool with no annotations or output schema, the description covers the core invocation context: stopped state, mode selection, source requirement, return artifacts, and non-restoration of transfer settings. The remaining gap is the semantics of start/points/chunk_points, though start and points are partially described in the schema.

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

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

Schema description coverage is only 40%, so the description must compensate. It usefully explains mode semantics and the source requirement, but it leaves start, points, and chunk_points semantically unexplained beyond the schema. This is partial compensation, not full.

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 leads with a concrete verb and resource: 'Save a stopped DHO814 acquisition as time/value CSV; return path and timing.' This clearly distinguishes the tool from sibling get_waveform by emphasizing file output and returned artifacts rather than in-memory retrieval.

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 states when the tool applies ('stopped' acquisition), gives mode guidance ('RAW/MAX read memory; NORM reads screen (required for math)'), and notes a prerequisite ('Analog source must be enabled with data'). It does not explicitly contrast with get_waveform or list when-not-to-use cases, so it stops short of a 5.

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

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

With no annotations provided, the description takes on the full burden of behavioral disclosure and does so thoroughly. It reveals a side effect ('Probes read and clear SCPI errors'), defines the evidence categories returned, and states a limitation ('measurement lists are not accuracy validation'). This goes well beyond the schema and gives the agent an accurate model of the tool's runtime 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?

Three sentences deliver the core purpose, default behavior, a critical limitation, a side effect, and the parameter switch, with zero filler. The main result is stated first, and every subsequent clause earns its place by adding operational or behavioral detail.

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

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

For a tool with one optional parameter, no annotations, and no output schema, the description covers all essential context: what it returns, how evidence is categorized, what the default does, how to opt out of probing, what not to use it for, and the SCPI error side effect. Nothing an agent needs 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?

The input schema provides no description for verify_hardware, so the description must compensate, and it does. It explains the parameter's role by contrasting the default probing behavior with 'Set verify_hardware=false for identity/model data only,' which is directly actionable for an agent deciding how to call the tool.

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 precise verb-object pair, 'Return model capabilities with per-field evidence,' and immediately clarifies what kinds of evidence are produced: hardware-verified, documented, or unverified. It further distinguishes the tool from likely siblings like idn by grounding it in DHO800/900 channel/grid counts and model mismatches.

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 clear context about default behavior and explicitly tells the caller when to set verify_hardware=false ('for identity/model data only'). It also warns that measurement lists are not accuracy validation, which helps prevent misuse, though it does not explicitly name alternative sibling 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 behavioral disclosure burden. It adds meaningful semantic context by explaining that AX_s/BX_s are in seconds, XY axes are amplitudes, and inv_delta_x is reciprocal separation rather than signal frequency. This helps prevent misinterpretation of returned values.

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-loaded with the core purpose, followed by two short sentences that clarify unit semantics. Every sentence adds useful information 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?

For a parameterless read tool, the description covers the essential behavior and key value semantics. It does not specify the exact return shape or mention whether cursors must be previously configured, but the low complexity and clear field explanations make it reasonably 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?

The tool has zero parameters, so parameter documentation is not needed. The description instead clarifies the meaning of the returned values, which is the relevant semantic content for this parameterless read tool.

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

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

The description clearly identifies a read operation on cursor values plus DHO source/type, using a specific verb and resource. It is distinguishable from siblings like set_cursors, though it does not explicitly name alternatives or contrast itself with other read tools.

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

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

Usage is implied: use this tool when you need to read cursor values rather than set them. However, the description does not explicitly state when to prefer this over related measurement tools, nor does it mention any prerequisites such as active cursors.

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 safety burden; saying 'Read' implies a non-destructive operation. It also discloses meaningful limitations: EDGE-only trigger details and no live channel/grid verification. However, it does not explain the return format, error behavior, or whether stale/model data is returned.

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 brief and front-loaded with the primary purpose. Both sentences add information: the first lists content, the second adds a caveat about model-based capabilities. Minor jargon in 'model capabilities' keeps it from being perfectly crisp.

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 no output schema and no annotations, the description should clarify what the returned data looks like and how to interpret it. It explains what is read and two caveats, but leaves key aspects—actual return structure, semantics of 'model capabilities', and possible errors—unstated.

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

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

The tool has zero parameters, so the empty schema is fully covered. The description correctly says nothing about parameters, and no additional parameter-level meaning is needed. Baseline 4 for a parameterless 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 states a specific verb ('Read') and resource ('channel settings, timebase and trigger mode/status'), making the tool's core function clear. It does not explicitly distinguish itself from siblings like get_capabilities or read_capture, but the listed contents are specific enough that an agent can infer the 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 guidance is provided about when to use this tool versus the many sibling getters. The phrase 'Includes model capabilities without live channel/grid verification' hints at a limitation but does not name alternatives or specify conditions that should lead the agent to another 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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It reveals important side effects: it does not stop acquisition, enables disabled channels, changes transfer settings, and that raw_data=true saves JSON and returns metadata/path, never samples. This is exceptionally transparent for a tool with zero annotation support.

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 dense with useful information, and the core purpose is front-loaded. It uses several short sentences that are efficient but slightly fragmented; each sentence earns its place, though a more consolidated structure would improve readability.

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

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

The description covers purpose, prerequisites, side effects, raw_data mode, and an alternative tool, making it largely complete for a simple two-parameter tool. However, it does not clearly describe what the normal (non-raw_data) response contains beyond 'suppressing unreliable interpretation', and 'NORM screen data' may be cryptic without additional context. An explicit return-value description would make it 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?

Schema coverage is only 50%, but the description compensates by clarifying raw_data behavior ('saves JSON and returns metadata/path, never samples') beyond the schema's brief note. The channel parameter is self-explanatory via its enum values and the NORM screen context, though the description could have added more explicit channel guidance.

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

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

The description clearly states the tool's function: 'Analyse NORM screen data (DHO 1000, DS1000Z up to 1200 points)'. It uses a specific verb ('Analyse') and resource ('NORM screen data'), and it explicitly distinguishes from the sibling tool download_waveform by saying 'Use download_waveform for memory'.

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

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

Provides explicit usage context and preconditions: 'Does not stop acquisition; stop first for consistency' and 'Enables disabled channels; acquisition may be needed'. It also names the alternative tool (download_waveform) and the condition for choosing it, giving clear when-to-use 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?

With no annotations, the description carries the full behavioral burden. It adds a critical warning: failure is reported in diagnostic text and the MCP success flag alone is insufficient. This goes beyond a simple 'read' statement and alerts the agent to inspect the actual output.

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

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

The description is two sentences with no filler. The first states the core function, and the second provides essential operational guidance. Every sentence earns its place and the most important warning is naturally integrated.

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, no-output-schema tool, the description provides sufficient context: what is read and how to interpret failure. It does not explicitly state that the operation is read-only, but the verb 'Read' strongly implies it, and no other behavioral details seem essential.

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

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

The tool has zero parameters and schema coverage is 100%, so the baseline for parameter semantics is 4. The description correctly focuses on behavior rather than parameter details, and no additional parameter documentation is needed.

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

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

The description uses a specific verb ('Read') with a clear resource: identity (model, serial, firmware) plus LAN/session/driver diagnostics. This is detailed enough to distinguish from siblings like get_capabilities or check_error, which target different data.

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 when to use the tool—whenever identity or diagnostic information is needed—but it does not explicitly state alternatives or exclusions. There is no mention of when not to use it or which sibling tool might be more appropriate for related but distinct queries.

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 side effects (registers the item on the scope, may populate results panel, enables disabled channels), prerequisites (live acquisition for DHO), the invalid sentinel 9.9E37, and measurement semantics. This is strong behavioral 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?

The description is front-loaded with the core purpose, then packs side effects, prerequisites, invalid values, and item semantics into three dense but purposeful sentences. Every sentence adds non-obvious information; 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?

In the absence of annotations and an output schema, this description covers what the tool returns, how its side effects behave, what preconditions exist, which values are invalid, and how key measurement items differ. That is sufficient for an agent to invoke the 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?

The schema gives item examples but little semantic depth; the description compensates by explaining VAMP, VPP, VRMS, PVRMS, and ACRMS meanings. Channel is adequately handled by the enum. It adds real value beyond the schema, though it does not describe every possible item.

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

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

The description clearly states the action ('Read a built-in measurement as text') and the resource ('a built-in measurement'), and mentions get_capabilities for item discovery. It does not explicitly contrast with sibling measure_between, so differentiation is slightly weaker than ideal.

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

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

The description provides actionable context: get_capabilities lists valid items, and DHO may need live acquisition before measurement. It lacks an explicit 'when not to use' statement or direct mention of alternatives like measure_between, but the usage context is reasonably 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, the description carries the behavioral burden and reveals important side effects: it registers a scope measurement, may populate the results panel, and enables disabled sources. It also discloses a precondition and an invalid value sentinel, though it does not describe the exact return shape or 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?

Four short sentences deliver purpose/units, item semantics, side effects, and operational caveats, with every sentence adding distinct value. The core action is front-loaded.

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

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

For a small three-parameter tool with no annotations or output schema, the description covers purpose, units, parameter interpretation, side effects, a device-specific precondition, and an invalid-result sentinel. An agent has enough information to select item values and know what to expect.

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

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

The schema already labels source1 and source2 (67% coverage); the description adds essential meaning to the cryptic item enum by explaining edge-letter order and DS1000Z-to-DHO mapping. This goes beyond the schema, though it leaves R/F expansion to the agent's domain knowledge.

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 phrase 'Read delay (seconds) or phase (degrees)' names a specific verb, resource, and unit, making the tool's core function unmistakable. This is clearly distinct from generic siblings like measure or get_scope_state.

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 clear context: this is for delay/phase measurements between two sources. It also supplies operational prerequisites and caveats (live acquisition on DHO, invalid sentinel 9.9E37), though it does not explicitly route the agent away from the sibling measure 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?

With no annotations provided, the description carries the full behavioral burden and does well: it discloses byte-offset pagination, truncation via escaping, UTF-8 boundary replacements, base64 losslessness, and scope restrictions. It does not cover all possible error conditions or return details, but the core behavioral traits are clearly communicated.

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-loaded with the most important scoping information. Every sentence adds meaningful guidance, from what files are read to how to handle pagination and encoding, with no filler or redundancy.

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

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

Given the tool has four undocumented parameters, no annotations, and no output schema, the description is notably complete: it covers scope, encoding trade-offs, pagination hints, and recommended usage. It does not fully define the return structure or error cases, but the references to next_offset and lossless base64 provide enough context for an agent to invoke 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 explain parameters, and it largely does: byte offsets clarify offset, UTF-8 versus base64 clarifies encoding, and 'read only needed excerpts' implies max_bytes usage. Path is partially clarified as being under RIGOL_DATA_DIR, but exact path semantics and next_offset (which appears only in prose, not the schema) could be more explicit.

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 reads generated data files under RIGOL_DATA_DIR, distinguishing it from screenshots and arbitrary files. It names a specific resource and action, and the contrast with siblings like screenshot and download_waveform makes its purpose 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 provides practical usage boundaries: it is not for screenshots or arbitrary files, and it has no scope access. It also gives guidance on reading only needed excerpts and choosing base64 for lossless reads, though it does not explicitly name alternative sibling tools for scope-related data.

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 of behavioral disclosure. It usefully warns that 'immediate status may lag' and directs the agent to confirm via get_scope_state, which is non-obvious and valuable. It does not discuss side effects or state changes, but for a simple zero-parameter start command this is reasonably transparent.

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

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

The description is two short sentences with no wasted words. The primary action is front-loaded, and the second sentence adds a necessary caveat and verification step. Every sentence earns its place.

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

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

For a zero-parameter, no-output-schema tool, this description covers the essential action and the key post-invocation behavior. It could slightly improve by explicitly pointing to siblings like single or stop for alternative modes, but the current wording is sufficient 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?

The tool has zero parameters and the input schema is empty with 100% schema description coverage. There are no parameter semantics for the description to clarify, so the baseline of 4 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 clearly identifies the operation as 'Start continuous acquisition,' naming a specific verb and resource. It also distinguishes itself from siblings like single and stop by specifying 'continuous' acquisition rather than single-shot or stopping behavior.

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

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

The description gives clear context for when to use the tool: when continuous acquisition should begin. It also provides a follow-up action ('Query get_scope_state to confirm'), which helps the agent verify the operation. However, it does not explicitly mention when not to use it or name alternatives like single or stop.

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 behavioral burden and does well: it discloses pagination ('10 per page'), filter precedence ('command ignores other filters'), scope limitation ('No scope access'), and a required workflow step. It stops short of explicitly saying the operation is read-only, but 'Browse' and 'Fetch details' strongly imply that.

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

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

Four short sentences, each carrying distinct information. The browse/detail purpose is front-loaded, and the warnings and workflow guidance are compressed without losing clarity.

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 five optional parameters and no output schema, the description covers browse, detail, filter, pagination, scope boundary, and the execution workflow. Offset semantics are only implicit, and the return shape is not specified, but the tool is simple enough that an agent can invoke it correctly.

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

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

The description adds meaning beyond the schema: '10 per page' gives paging semantics to limit/offset, 'pass command... signature, parameter types/enums' adds detail to the command parameter, and 'command ignores other filters' clarifies parameter interaction. This compensates for the 60% schema coverage gap on limit/offset.

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 'Browse DHO814 command names' and clearly distinguishes catalog browsing from detail retrieval ('pass command for one signature, parameter types/enums and manual section'). 'No scope access' and 'Fetch details before scpi_execute' orient this tool against sibling scope-control and execution tools.

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 the two main usage modes, browse vs exact command lookup, and gives filter direction ('Filter by subsystem or search'). 'command ignores other filters' is a concrete exclusion, and 'Fetch details before scpi_execute' provides workflow guidance. It does not explicitly name alternatives for when not to use this tool, but the usage context is clear.

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

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

With no annotations provided, the description carries the full burden and succeeds admirably. It discloses destructive capabilities (overwrite files, reset, change LAN or lock controls), non-reset write error draining, query status/error consumption, and lack of retries or completion guarantees. This is exemplary transparency.

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 dense and information-rich with zero filler. The core purpose is front-loaded in the first sentence, and each subsequent sentence adds a distinct behavioral or usage constraint. Every word 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?

This is a complex, dangerous tool with 6 parameters and no output schema, and the description covers safety, side effects, data handling, and execution semantics exceptionally well. The only notable gap is the absence of return-value/response format information, which matters because no output schema exists to fill that void.

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

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

Schema description coverage is only 50%, but the description compensates by adding critical meaning: positional argument ordering, inline_binary size limit of 1024 bytes, and file-backed handling for large text/binary data. This significantly clarifies parameters not described 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 clearly states the specific action (execute) and resource (one DHO814 catalog command), and mentions positional arguments, which distinguishes it from catalog listing tools like scpi_catalog. The purpose is immediately understandable and unique among 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?

The description provides extensive usage context, including data size limits, file-backed handling, scope-enforced limits, error-draining behavior, and safety caveats. It does not explicitly name alternative tools or give when-not-to-use conditions, but the contextual guidance is strong enough to guide correct invocation.

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 behavioral burden. It states the core output (saves PNG, returns path) and the intended use, but it does not clarify what include_image=false actually changes about the response or whether files persist/overwrite. That leaves some behavior implicit, though not misleading.

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, zero filler, and the most important instruction is front-loaded. Every clause contributes either the action or the usage constraint.

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

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

For a single-optional-parameter tool with no output schema, the description covers the action, return type, and routing. It lacks explicit details about include_image=false behavior and possible side effects of saving a file, but these are minor for a simple screenshot operation.

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

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

The schema provides only name/default with 0% description coverage, so the description must compensate. It does by explaining when to set include_image=true ('only when visual inspection is necessary') and when to avoid the tool. It could be stronger by specifying the effect on the returned payload, but it provides a usable decision rule.

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 and resource: 'Save a display PNG and return its path.' This clearly differentiates the tool from sibling data-acquisition tools like get_waveform and measure, which pull numeric traces rather than images.

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 an explicit decision rule: set include_image=true only for visual inspection, otherwise prefer measure/get_waveform. This tells an agent exactly when to call this tool versus named alternatives.

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 discloses that the tool returns a readback, that probe ratio is applied before scale/offset, and that changing probe ratio may rescale existing values. These are meaningful behavioral traits beyond the 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?

Three concise sentences with no filler. The main action is front-loaded, followed by the return value and the most important caveat. Every sentence contributes useful 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 mutating tool with no output schema and no annotations, the description covers the core action, return behavior, an important side effect, and a precondition. It could be slightly more explicit about unspecified settings remaining unchanged, but overall it is adequately 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 67%, and the description adds important semantic context for probe ratio and its interaction with scale/offset. It does not describe every parameter, but the schema itself covers most parameter meanings via descriptions and enums.

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?

Description states a specific verb and resource ('Change specified channel settings') and mentions the return of channel readback. It clearly distinguishes this tool from sibling set_* tools by targeting channel settings rather than timebase, trigger, or cursors.

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

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

Provides clear context for use: changing channel settings, with a precondition that the channel must be installed. It does not explicitly compare to alternatives like set_timebase or set_trigger, but the channel-specific scope makes the intended use 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, the description carries the full burden and does substantial work: state retention ('omitted mode is retained'), hardware restriction ('DHO-only'), a prerequisite ('requires XY timebase'), and rejection behavior ('rejects positions here'). It stops short of disclosing error outcomes, whether settings persist across sessions, or side effects on existing measurements, so it's 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?

Extremely dense with zero filler: the first clause names the operation and return, and each subsequent clause adds one distinct constraint or routing rule. Front-loads the core purpose before diving into mode-specific details.

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

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

For a 10-parameter, 4-mode tool with no annotations and no output schema, the description covers the hard parts: mode validations, DHO-only quirks, and alternative routing to scpi_execute. Gaps remain on the return readout format (no output schema to back it up) and cursor_type's interaction with modes, but those are minor against the breadth covered.

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

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

Schema already covers 70% of parameters with descriptive text; the description adds the crucial mode→parameter mapping (which params are valid in which mode) and the OFF/XY constraints, directly compensating for the three undocumented enums (mode, track_axis, cursor_type). The value added is meaningful but not exhaustive – cursor_type semantics are only implicitly covered by 'type for MANUAL'.

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

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

States a specific verb and resource ('Set cursors') plus output behavior ('return readouts'), and differentiates itself from sibling scpi_execute by explicitly reserving XY positioning for that tool on DHO814. An agent can distinguish this from get_cursor_values (read) and scpi_execute (generic command execution) 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?

Provides explicit mode-to-parameter routing: MANUAL uses source/type, TRACK uses source_a/source_b/track_axis, OFF accepts no positions or sources, and XY requires an XY timebase and belongs on scpi_execute instead. This is exactly the when-and-when-not guidance a selector needs, including a named alternative.

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 behavioral burden and does add real value: it says the tool returns configuration, provides instrument-specific edge-offset formulas, and corrects the assumption that trigger level must be zero. It does not cover side effects or prerequisites, but it reveals meaningful behavior beyond the 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?

Three sentences with the primary action front-loaded. The second and third sentences add relevant behavioral and usage detail without repeating the schema. A couple of phrases are terse, 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?

For a two-optional-parameter tool with no output schema, the description adequately covers operation, return value, and edge behavior. Missing pieces include valid value ranges, behavior when parameters are omitted, and a clearer explanation of zoom/noncentral references in relation to 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 coverage is 100%, so the baseline is 3. The description adds semantic context by relating scale_s_div to horizontal scale and window-edge offset calculations, and by clarifying the nature of offset_s as a trigger offset. It does not add ranges or format guidance, but it enriches the two parameters beyond the bare schema descriptions.

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 and resource: 'Set horizontal scale/offset; return configuration.' This clearly identifies it as the timebase configuration tool and distinguishes it from sibling setters like set_channel and set_trigger. It does not explicitly name an alternative, 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?

Usage context is implied rather than explicit: the tool sets horizontal scale and offset, and the note about 'zoom/noncentral references' gives task-oriented guidance. However, it never states when to prefer this tool over siblings, whether it is only for timebase changes, or when it should not be used.

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 behavioral burden and does so well. It reveals a surprising default behavior (always selects EDGE even with no arguments), promises a readback return, and flags model-specific EXT availability. It does not cover validation or failure behavior, but there is no contradiction with any structured metadata.

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

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

Two sentences, front-loaded with the most important default behavior, followed by compact parameter and compatibility notes. Every sentence earns its place with no filler or repetition.

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

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

The description covers the core behavior, no-argument default, return type, slope semantics, and model-specific source limitations, while the schema handles level and source. It lacks only an explicit readback format and a usage-vs-alternatives note, neither of which is critical for this simple setter.

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

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

The schema already documents level and source, so the description adds value by explaining the slope enum meanings (POS rises, NEG falls, RFAL accepts either edge) and the EXT source model limitations. With schema description coverage at 67%, this is a solid supplement rather than redundant.

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 leads with 'Always selects EDGE, even with no arguments', making the operation and default behavior explicit. It clearly identifies the trigger domain and explains slope options, so an agent can distinguish it from channel or timebase setters. It stops short of an explicit 'Sets the trigger' framing, but the intended action is unambiguous.

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

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

The description gives concrete selection guidance: POS means rising edge, NEG means falling edge, RFAL accepts either edge, and EXT is only available on specific models. It does not name sibling tools or state when to prefer this over scpi_execute, but for a dedicated setter the context is sufficient.

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

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

No annotations exist, so the description carries the burden of behavioral disclosure. It reveals the non-blocking/asynchronous nature of the call and the precondition check for downloads, which are important behavioral traits beyond the tool name.

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 concise, purposeful sentences. The main action is front-loaded, and the important follow-up check is included without unnecessary detail.

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 parameterless tool, the description provides the essential action and the relevant follow-up state check. It does not detail possible status return values or trigger configuration prerequisites, but these are not strictly required to invoke the tool.

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

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

The tool has zero parameters and an empty schema, so parameter documentation is not needed. Baseline 4 applies because there are no parameters to explain.

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

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

The description states a specific action ('Arm one acquisition') and clearly specifies the behavior ('return status without waiting for its trigger'). This distinguishes it from related tools like run, stop, and set_trigger.

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 clear context for when to use the tool: arm one acquisition and do not block waiting for the trigger. It also instructs checking get_scope_state for STOP before downloading, providing a sequencing guideline, though it does not explicitly name alternative tools or exclusions.

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

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

With no annotations, the description carries the full behavioral burden. It discloses that the tool is non-destructive, that status reporting may lag, and that the expected way to confirm completion is through get_scope_state. This covers the key behavioral traits and caveats an agent needs.

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

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

Three short sentences, each earning its place: the action and retention scope, the status-lag caveat with verification guidance, and the explicit exclusion of destructive behavior. No filler or redundancy.

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

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

For a paramless action with no output schema, the description is complete. It explains what the tool does, what it preserves, how to confirm the result, and what it is not. An agent has enough guidance to invoke it correctly and avoid misinterpreting lagging status.

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 input schema has no parameters, so the description bears no burden for parameter explanations. Per the baseline for zero parameters, a 4 is appropriate because there is no missing semantic information about arguments.

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 clear verb and resource: 'Stop acquisition'. It specifies what is retained ('displayed trace and settings') and explicitly disambiguates from destructive operations via 'Not a clear or factory reset.' This is specific enough to distinguish it from run, single, and autoscale.

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 clear context: this stops acquisition while preserving the current trace and settings. It also provides a verification path ('confirm STOP via get_scope_state') and an exclusion ('Not a clear or factory reset'). It does not explicitly contrast with run or single, but the intended usage is clear for a zero-parameter action.

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