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

With no annotations provided, the description carries the full burden and adds valuable behavioral context: it discloses that the operation 'takes a few seconds' (indicating latency) and that the resulting configuration is not immediately visible (requiring a follow-up call to 'get_scope_state'). This goes beyond the basic action, though it could mention more about potential side effects or errors.

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 action, followed by important behavioral notes, all in two efficient sentences with zero waste. Every sentence earns its place by providing critical information without redundancy.

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

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

Given the tool's complexity (an auto-setup operation with no parameters) and lack of annotations or output schema, the description is reasonably complete: it explains what the tool does, its duration, and the need to check results. However, it could be more comprehensive by mentioning potential failure modes or what 'auto-setup' entails in more detail, preventing a perfect score.

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 0 parameters with 100% coverage, so no parameter documentation is needed. The description appropriately does not discuss parameters, focusing instead on behavior and usage. A baseline of 4 is applied since it handles the zero-parameter case well without unnecessary details.

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 ('run the scope's auto-setup') and specifies what it configures ('timebase, vertical scale, trigger'), making the purpose understandable. However, it does not explicitly differentiate this from sibling tools like 'set_timebase' or 'set_trigger', which handle manual configuration of those same components, so it falls short of a perfect score.

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

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

The description provides clear context by stating 'Takes a few seconds' and instructing to 'call get_scope_state afterwards to see the resulting configuration,' which guides when to use it (after running, to check results). It does not explicitly mention when not to use it or alternatives (e.g., manual setup tools), so it's not a full 5.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It describes the return behavior (error or 'No error'), which is useful, but does not cover other aspects like permissions needed, rate limits, or whether it clears the error queue. It adds some value but lacks comprehensive behavioral context for a tool that queries system state.

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

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

The description is two sentences with zero waste: the first states the purpose, and the second specifies the return behavior. It is front-loaded with the core action and efficiently conveys necessary information without unnecessary 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?

Given the tool's simplicity (0 parameters, no output schema, no annotations), the description is complete enough to understand its basic function. However, for a tool that queries error states, it could benefit from more context on error formats, when errors occur, or how it interacts with other tools, leaving some gaps in full understanding.

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 0 parameters with 100% coverage, so the schema fully documents the lack of inputs. The description adds no parameter information, which is appropriate here, but does not compensate for any gaps since there are none. A baseline of 4 is given as it adequately handles the zero-parameter case without redundancy.

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 ('Query the SCPI error queue') and the resource ('SCPI error queue'), distinguishing it from all sibling tools which involve measurement, configuration, or control operations. It precisely defines what the tool does without restating the name.

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

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

The description implies usage context by stating it 'Returns the error if present, or 'No error' if clear,' suggesting it should be used to check error status after operations. However, it does not explicitly state when to use this tool versus alternatives or provide exclusions, leaving some ambiguity about its specific application scenarios.

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 states this is a read operation, implying it is non-destructive, but does not cover other traits like error handling, rate limits, or authentication needs. The mention of 'AX_s and BX_s are time positions in seconds' adds some context about output format, but overall, behavioral information is minimal.

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

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

The description is concise and front-loaded, with two sentences that directly state the tool's purpose and provide additional context. There is no wasted text, and each sentence adds value, making it efficient and well-structured.

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 0 parameters and no output schema, the description is moderately complete. It explains what the tool does and provides some output details, but lacks information on behavioral aspects like error handling or usage context. For a read-only tool with no annotations, it could be more comprehensive to fully guide the agent.

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

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

The tool has 0 parameters, with 100% schema description coverage (since there are no parameters to describe). The description does not need to compensate for any parameter gaps, and it adds value by explaining output semantics ('AX_s and BX_s are time positions in seconds'), which is beyond the empty input schema. This meets the baseline for 0 parameters.

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

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

The description clearly states the tool's purpose: 'Read current cursor mode and all cursor readouts.' This specifies the verb ('Read') and the resource ('cursor mode and all cursor readouts'), making it understandable. However, it does not explicitly differentiate from sibling tools like 'set_cursors' or 'measure_between', which might involve cursor operations, so it lacks sibling differentiation.

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

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

The description provides no guidance on when to use this tool versus alternatives. It does not mention any context, prerequisites, or exclusions, such as when to prefer 'get_cursor_values' over 'measure' or 'get_scope_state' for cursor-related data. This leaves the agent without usage direction.

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 full burden and does well by specifying it returns a 'snapshot' (implying read-only, non-destructive behavior) and clarifies it captures 'current configuration.' It doesn't mention rate limits or authentication needs, but for a read-only tool with zero parameters, 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 front-loaded with the core purpose in the first sentence, followed by a usage guideline. Both sentences earn their place by providing essential information without redundancy or fluff, making it highly efficient.

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

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

Given the tool's complexity (read-only, 0 parameters) and lack of annotations/output schema, the description is mostly complete. It explains what the tool does and when to use it, though it could benefit from mentioning the return format or data structure for the snapshot.

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 0 parameters with 100% schema description coverage, so the baseline is 4. The description adds no parameter information, which is appropriate since none are needed, maintaining the baseline score.

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

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

The description clearly states the specific action ('Return a snapshot') and resource ('scope's current configuration'), listing key components like active channels, timebase, and trigger. It distinguishes from siblings by focusing on configuration retrieval rather than measurement, waveform capture, or control functions.

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?

Explicit guidance is provided on when to use this tool: 'Call this at the start of a session to understand the current setup.' This clearly indicates the intended context and timing for usage, distinguishing it from tools meant for ongoing operations or error checking.

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 effectively describes key behaviors: it requires stopping/single-triggering the scope first, returns either text analysis or raw JSON arrays based on a parameter, includes data-quality warnings, and provides actionable advice for handling specific warning cases like adjusting timebase or offset.

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 appropriately sized and front-loaded, starting with the core purpose and immediate prerequisites. Each sentence adds value, such as explaining output options and post-analysis actions, with no redundant information, though it could be slightly more streamlined by integrating warning handling more succinctly.

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's complexity (waveform analysis with warnings and raw data options), no annotations, and no output schema, the description is largely complete. It covers purpose, usage, parameters, and behavioral aspects, but lacks details on exact output formats or error cases, leaving some gaps for an agent to infer.

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 50% (only raw_data has a description). The description adds significant value by explaining the channel parameter's purpose ('for a channel') and the raw_data parameter's effect ('returns a plain-text analysis... Set raw_data=true to get the full time/voltage JSON arrays'), compensating for the schema's lack of channel description and enriching raw_data context.

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 purpose with specific verbs ('download and analyse') and resource ('current waveform for a channel'), distinguishing it from siblings like 'get_scope_state' or 'measure' by focusing on waveform data extraction and analysis rather than general scope information or measurements.

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 explicit usage guidance: it instructs to 'stop or single-trigger the scope first for consistent data,' specifies when to use raw_data=true for raw arrays versus default text analysis, and advises on post-processing actions based on warnings, offering clear alternatives and 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?

With no annotations provided, the description carries the full burden. It discloses the return values (make, model, serial, firmware version) and the purpose (verification), but lacks details about error conditions, timing, or whether this is a read-only operation. The description doesn't contradict any 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?

The description is perfectly concise with two sentences: one stating the purpose and return values, another providing usage guidance. Every word earns its place with zero waste.

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 annotations or output schema, the description provides good context about what the tool does and when to use it. However, it could be more complete by mentioning whether this is a read operation or if it has any side effects.

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 0 parameters with 100% schema coverage, so the baseline is 4. The description appropriately doesn't discuss parameters since none exist, focusing instead on the tool's purpose and usage.

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 purpose: 'Identify the instrument' with specific outputs (make, model, serial, firmware version). It distinguishes from siblings by focusing on identification rather than measurement or configuration, though it doesn't explicitly name alternatives.

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

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

The description provides clear context for when to use this tool: 'Use to verify connectivity before starting a measurement session.' This gives practical guidance, though it doesn't specify when NOT to use it or name specific alternative 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 provided, the description carries the full burden of behavioral disclosure. It effectively describes critical behaviors: the requirement to stop acquisition for stable readings, the meaning of the invalid/overflow sentinel value (9.9E37), and troubleshooting advice for specific cases like FREQUENCY errors. It does not cover all possible edge cases or error conditions, but provides substantial operational guidance.

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 appropriately sized and front-loaded, starting with the core purpose and immediate prerequisites. The list of items is necessary for clarity, and the explanation of the sentinel value and alternative tool usage adds value without redundancy. It could be slightly more structured but remains efficient and informative.

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's complexity (measurement operations with potential errors) and lack of annotations or output schema, the description is largely complete. It covers purpose, usage, parameters, and key behavioral aspects like the sentinel value and acquisition requirement. It does not detail the return format or all error scenarios, but provides sufficient context for effective use.

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

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

Schema description coverage is 50% (only 'item' has a description), but the description compensates well. It explains the 'channel' parameter range (CHAN1–CHAN4) and provides a comprehensive list of valid 'item' values with examples, adding significant meaning beyond the schema's enum and basic description. The description effectively clarifies parameter usage and constraints.

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 ('Query a single-source built-in measurement') and resource ('on a channel'), distinguishing it from sibling tools like 'measure_between' for two-channel measurements. It provides a comprehensive list of measurable items, making the purpose explicit and distinct.

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 explicitly states when to use this tool ('Query a single-source built-in measurement') and when not to ('For delay or phase between two channels use measure_between'). It also provides prerequisites ('Stop acquisition first for stable readings') and troubleshooting guidance for invalid results, offering clear alternatives and 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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It adds important context about the need to 'stop acquisition first for stable readings,' which reveals a critical operational constraint. However, it doesn't describe what the tool returns (numeric values? units?), error conditions, or performance characteristics like response time or rate limits. The description provides some behavioral insight but leaves significant gaps.

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 perfectly concise and well-structured. Three sentences each serve distinct purposes: (1) states the core function, (2) explains parameter roles and item meanings, (3) provides critical usage prerequisite. No wasted words, front-loaded with the main purpose, and efficiently delivers necessary information.

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

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

Given 3 parameters with partial schema coverage (67%), no annotations, and no output schema, the description does a decent job but has notable gaps. It explains parameter semantics well and provides a usage prerequisite, but doesn't describe return values (critical for a measurement tool), error handling, or system state requirements beyond the acquisition stop. For a measurement query tool with no structured output documentation, this leaves the agent guessing about 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?

Schema description coverage is 67% (2 of 3 parameters have descriptions). The description adds meaningful semantics beyond the schema: it explains that 'source1 is the reference channel' and 'source2 is the measured channel,' clarifying the directional relationship. It also defines the 'item' enum values (RDELAY=rising-edge delay in seconds, etc.), which the schema lacks. This compensates well for the schema's gaps, though it doesn't cover all possible parameter nuances.

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 purpose: 'Query a two-source delay or phase measurement between two channels.' It specifies the verb ('query'), resource ('measurement'), and distinguishes it from siblings like 'measure' (general) or 'get_cursor_values' (cursor-based). The description provides specific measurement types (RDELAY, FDELAY, RPHASE, FPHASE), making it highly differentiated.

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

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

The description includes explicit usage guidance: 'Stop acquisition first for stable readings.' This provides a clear prerequisite context. However, it doesn't specify when to use this tool versus alternatives like 'measure' or 'get_cursor_values' for similar measurements, nor does it mention exclusion cases. The guidance is helpful but incomplete regarding sibling differentiation.

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

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

With no annotations, the description carries the full burden. It mentions that it 'Returns trigger status after the command,' which adds some behavioral context about the output. However, it lacks details on side effects, error handling, or operational constraints like rate limits or dependencies.

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

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

The description is a single, efficient sentence that front-loads the main action ('Start continuous acquisition') and adds necessary output information. There is no wasted text, making it highly concise and well-structured.

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 0 parameters and no output schema, the description covers the basic action and output. However, as a tool likely involved in system control (with siblings like 'stop' and 'single'), it lacks details on behavior, error cases, or integration context, making it minimally adequate but incomplete.

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

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

The input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description appropriately doesn't discuss parameters, focusing instead on the tool's action and output, which aligns with the schema's simplicity.

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 ('Start continuous acquisition') and resource ('acquisition'), making the purpose understandable. However, it doesn't differentiate from sibling tools like 'single' or 'measure' that might also involve acquisition, leaving room for ambiguity.

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

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

No guidance is provided on when to use this tool versus alternatives such as 'single' or 'measure'. The description implies it's for starting continuous acquisition but doesn't specify prerequisites, stopping conditions, or when other tools might be more appropriate.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes the action (capture), output (image and absolute path), and format (PNG), covering key behavioral aspects. However, it lacks details on potential side effects, permissions, or error conditions, which would enhance transparency further.

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 highly concise and front-loaded, consisting of two sentences that directly state the action and the return values. Every sentence earns its place by providing essential information without any waste, making it efficient and easy to understand.

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's simplicity (0 parameters, no annotations, no output schema), the description is nearly complete. It covers the purpose, action, and output format adequately. However, it could be more complete by including details like error handling or file naming conventions, which would help in edge cases.

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 0 parameters with 100% coverage, so no parameter documentation is needed. The description appropriately avoids redundant parameter details, focusing instead on the tool's function and output. This aligns with the baseline expectation for tools without parameters, adding value by clarifying the output.

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 ('Capture a screenshot') and the target resource ('oscilloscope display'), distinguishing it from sibling tools like get_waveform or get_scope_state that retrieve data rather than capture visual output. It precisely defines the tool's function without being vague or tautological.

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

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

The description implies usage when a visual capture of the oscilloscope display is needed, but it does not explicitly state when to use this tool versus alternatives (e.g., get_waveform for numerical data). No guidance is provided on prerequisites, timing, or exclusions, leaving usage context inferred rather than clearly defined.

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 effectively describes key behaviors: queries return response strings, writes return empty strings, and writes auto-check the error queue. It doesn't mention error handling for malformed commands or rate limits, but covers the core operational behavior well.

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 perfectly concise with two sentences that each earn their place. The first sentence explains the core functionality and behavior, while the second provides crucial usage guidance. There is zero wasted text 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's complexity (low-level SCPI interface), single parameter, 100% schema coverage, and no output schema, the description is quite complete. It explains what the tool does, when to use it, and the different behaviors for queries vs. writes. The main gap is lack of output format details for queries, but this is reasonable for an 'escape hatch' 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 100%, so the schema already documents the single parameter. The description adds marginal value by providing example commands (':CHAN1:SCAL?' and ':CHAN1:DISP ON') that illustrate the parameter's purpose, but doesn't add significant semantic information beyond what the schema provides.

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 purpose with specific verbs ('send an arbitrary SCPI command') and distinguishes it from siblings by positioning it as an 'escape hatch when no dedicated tool covers the operation.' It explicitly identifies the resource (SCPI commands) and differentiates from other tools like set_channel or measure.

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 explicit guidance on when to use this tool ('when no dedicated tool covers the operation') and when not to use it (implied: use dedicated tools when available). It also distinguishes between query and write operations, offering clear context for usage decisions.

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 adds useful context: 'Only specified parameters are changed' (partial updates), 'Parameter names match get_scope_state output for easy round-tripping' (compatibility), and 'Returns the resulting channel configuration' (output behavior). However, it doesn't cover permissions, error conditions, or side effects, leaving gaps for a mutation tool.

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

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

The description is efficiently structured: first sentence states the core action, followed by key behavioral notes and parameter details, ending with return information. Every sentence adds value—no fluff or repetition. It's appropriately sized for a tool with 6 parameters and no annotations.

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

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

Given the tool's complexity (mutation with 6 parameters), no annotations, and no output schema, the description does a solid job. It covers purpose, partial update behavior, parameter semantics, and return value. However, it lacks error handling, prerequisites (e.g., device state), and doesn't fully explain all parameters (e.g., 'display' is only in schema). It's mostly complete but has minor gaps.

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

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

Schema description coverage is 67% (4 out of 6 parameters have descriptions). The description adds value beyond the schema by explaining that 'channel: CHAN1–CHAN4' (clarifying range), 'scale_v_div: V/div' (units), 'offset_v: volts' (units), 'coupling: AC, DC, or GND' (options), and 'probe: attenuation ratio (1, 10, 100, …)' (examples). It compensates well for the schema's gaps, though not perfectly.

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 purpose: 'Configure a channel' with specific parameters like scale, offset, coupling, and probe. It distinguishes itself from siblings like 'set_timebase' or 'set_trigger' by focusing on channel configuration rather than timebase or trigger settings. However, it doesn't explicitly differentiate from all siblings (e.g., 'set_cursors'), so it's not a perfect 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?

The description provides some implied usage context: 'Only specified parameters are changed' and mentions round-tripping with 'get_scope_state'. However, it doesn't explicitly state when to use this tool versus alternatives like 'autoscale' or 'measure', nor does it provide exclusions or prerequisites. The guidance is helpful but not comprehensive.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool sets cursor modes and positions and returns readouts, but lacks details on permissions, side effects, error handling, or rate limits. For a mutation tool with zero annotation coverage, this is insufficient to inform safe and effective use.

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

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

The description is concise and front-loaded, stating the core purpose in the first clause. It efficiently explains parameter behavior and the return value in two sentences. There's no unnecessary verbiage, though it could be slightly more structured for 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 the tool's complexity (mutation with 3 parameters) and lack of annotations and output schema, the description is incomplete. It doesn't cover error cases, response format details beyond 'readouts', or integration with sibling tools. For a tool that modifies state, more context is needed to ensure reliable use.

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

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

Schema description coverage is 67%, with 'ax' and 'bx' documented in the schema but 'mode' lacking a description. The description adds value by explaining that 'mode' can be omitted to keep current and lists the enum values, partially compensating for the coverage gap. However, it doesn't fully clarify the semantics of 'ax' and 'bx' beyond what the schema provides, resulting in a baseline score.

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

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

The description clearly states the tool's purpose: 'Set cursor mode and/or X positions.' It specifies the verb ('Set') and resource ('cursor mode and/or X positions'), making it easy to understand what the tool does. However, it doesn't explicitly differentiate from sibling tools like 'get_cursor_values' or 'measure_between', which might involve cursor operations, so it misses full sibling distinction.

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 minimal guidance: it mentions that parameters can be omitted to keep current values, but offers no explicit advice on when to use this tool versus alternatives. There's no mention of prerequisites, context, or comparison with sibling tools like 'get_cursor_values' for reading cursor data, leaving usage unclear.

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

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

With no annotations provided, the description carries the full burden. It effectively discloses that this is a configuration/mutation tool (implied by 'Set'), explains the mathematical relationship between parameters and display window, and describes the return value. It doesn't mention permission requirements, rate limits, or error conditions, but provides substantial behavioral context.

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 efficiently structured with zero wasted sentences. It front-loads the core purpose, then provides essential formulas and practical examples, and concludes with integration notes and return information. Every sentence serves a clear purpose in helping an agent understand and use the tool correctly.

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 2-parameter configuration tool with no annotations or output schema, the description provides excellent coverage of purpose, parameter semantics, and behavioral context. It explains the mathematical model and practical usage patterns thoroughly. The only minor gap is the lack of explicit error handling or validation constraints information.

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?

Despite 100% schema description coverage, the description adds significant value beyond the schema. It explains the practical meaning of parameters with formulas (time_start = offset_s − 6×scale_s_div), provides usage examples for alignment scenarios, and clarifies the relationship to trigger positioning. This transforms abstract parameter definitions into actionable 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 specific action ('Set the horizontal timebase') and resource ('timebase'), distinguishing it from sibling tools like set_channel or set_trigger. It provides a precise technical definition of what the tool does, going beyond a simple verb-noun pairing.

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

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

The description provides clear context for when to use this tool (to configure timebase parameters) and mentions alignment with get_scope_state output for round-tripping. However, it doesn't explicitly state when NOT to use it or name specific alternatives among siblings like autoscale.

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

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

No annotations are provided, so the description carries the full burden. It mentions the return value ('Returns the resulting trigger configuration'), which is helpful, but does not disclose critical behavioral traits such as whether this is a destructive operation, if it requires specific permissions, or potential side effects like resetting other settings. For a configuration tool with zero annotation coverage, this is insufficient.

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, followed by parameter explanations and return value, all in two efficient sentences. Every sentence adds value without redundancy, making it highly concise and well-structured.

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 complexity (a configuration tool with 3 parameters), no annotations, and no output schema, the description is moderately complete. It covers parameter semantics and the return value, but lacks behavioral context and usage guidelines. For a tool that likely interacts with hardware (oscilloscope), more detail on effects and constraints would be 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 description adds significant meaning beyond the input schema. It explains the semantics of 'source' (CHAN1–CHAN4 or EXT), 'slope' (POS, NEG, RFAL with definitions), and 'level' (in volts), which complements the schema's 67% coverage (only 'source' and 'level' have descriptions). This compensates well for the schema's gaps, especially for 'slope' which lacks a description but is clarified in the tool 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?

The description clearly states the action ('Configure edge trigger') and specifies the resource ('edge trigger'), distinguishing it from sibling tools like set_channel or set_timebase. It provides specific details about what is being configured, making the 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 lacks guidance on when to use this tool versus alternatives. It does not mention prerequisites, such as whether the scope must be in a certain state, or compare it to other trigger-related tools (none listed in siblings). This leaves the agent without context for appropriate tool selection.

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

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

With no annotations provided, the description carries the full burden and does well by disclosing key behavioral traits: it's a mutation tool (arms the scope), it stops automatically after one trigger, returns trigger status, and notes that acquisition completion depends on a trigger occurring. It doesn't cover permissions or rate limits, but provides substantial operational context.

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 efficiently structured in two sentences: the first states the core action and behavior, the second adds crucial notes about completion and follow-up actions. Every sentence earns its place with 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 mutation tool with no annotations and no output schema, the description provides good context about what the tool does, its automatic stopping behavior, and important notes about trigger dependency. It could be more complete by explicitly describing the return format of 'trigger status' or error conditions, but it's substantially helpful.

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 0 parameters with 100% schema description coverage, so the baseline is 4. The description doesn't need to add parameter information, and it appropriately focuses on behavior instead.

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 purpose with specific verbs ('arm', 'stops', 'returns') and resources ('scope', 'acquisition', 'trigger status'). It distinguishes from siblings like 'run' (continuous) and 'stop' (manual) by specifying it's for a single acquisition that stops automatically after one 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?

The description provides clear context on when to use this tool: for arming the scope for a single acquisition that stops automatically after a trigger. It implies usage vs. alternatives like 'run' (continuous) and 'stop' (manual), but doesn't explicitly name them or state 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?

No annotations are provided, so the description carries full burden. It discloses the tool's effect (stops acquisition, freezes display) and return value (trigger status), but doesn't mention potential side effects like whether this affects subsequent measurements, if it requires specific device state, or latency considerations. The description adds value but lacks comprehensive behavioral context.

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

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

Two sentences with zero waste. First sentence states purpose and usage context, second sentence discloses return value. Every word earns its place and information is front-loaded appropriately.

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 annotations and no output schema, the description provides good context about what the tool does, when to use it, and what it returns. However, it doesn't fully explain the 'trigger status' return value or potential error conditions, leaving some gaps in completeness.

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 0 parameters with 100% schema description coverage. The description appropriately doesn't waste space discussing nonexistent parameters, maintaining focus on the tool's purpose and usage. Baseline for 0 parameters is 4.

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

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

The description clearly states the tool's purpose with specific verbs ('stop acquisition', 'freeze the display') and identifies the resource (oscilloscope acquisition/display). It distinguishes from siblings like 'run' (which would start acquisition) and 'single' (which captures one acquisition).

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?

Explicit guidance is provided on when to use this tool: 'before reading measurements or cursors for stable values.' This tells the agent precisely when this tool is needed versus alternatives like directly reading measurements without stopping acquisition.

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