lab-equipment-mcp
Server Quality Checklist
Latest release: v0.1.0
- Disambiguation4/5
Most tools are clearly separated by instrument prefix and specific verb-noun combinations, but there is overlap between generic SCPI command tools (e.g., dpo2012b_command vs. dpo2012b_query_scpi/write_scpi) that could confuse an agent.
Naming Consistency4/5The majority use instrument_model_verb_noun, but there is a mix with generic un-prefixed tools and some inconsistency between 'set' and 'configure' prefixes (e.g., set_mode_enabled vs. configure_modulation). Nevertheless, the pattern is largely predictable.
Tool Count1/5116 tools is extremely high. Even accounting for multiple instruments, the toolset is bloated with extensive per-instrument repetition and redundant generic SCPI tools, making it overwhelming and hard to navigate.
Completeness4/5The toolset covers core lifecycle and configuration operations for each device, including connect/disconnect, identify, settings, waveform setup, measurements, and generic SCPI access. Minor gaps like dedicated channel settings for oscilloscopes are workable via write_scpi.
Average 3.7/5 across 95 of 116 tools scored. Lowest: 2.5/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 33 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add
glama.jsonto the root of your repository:{ "$schema": "https://glama.ai/mcp/schemas/server.json", "maintainers": [ "your-github-username" ] }Then . Browse examples.
Add related servers to improve discoverability.
How to sync the server with GitHub?
Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.
To manually sync the server, click the "Sync Server" button in the MCP server admin interface.
How is the quality score calculated?
The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).
Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.
Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).
Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.
Tool Scores
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are all false but offer no positive safety hints. The description adds no behavioral context such as side effects on existing burst settings, required instrument connection state, or whether it enables burst mode. With annotations providing minimal value, the description carries the burden and fails to disclose meaningful behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one sentence with no wasted words, but it is so brief that it sacrifices essential detail. It is not verbose, but the extreme brevity limits its usefulness, making it merely average for this dimension.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 7 parameters, no schema descriptions, and no useful annotations, the description is woefully incomplete. It fails to explain how to specify the channel, valid mode values, cycle counts, timing parameters, or trigger source, making it nearly impossible for an agent to invoke correctly without external knowledge.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must explain the parameters. It only hints at the 'mode' parameter by naming the three modes, but completely ignores cycles, channel, enabled, period_s, phase_degrees, and trigger_source. This is minimal and inadequate for a 7-parameter tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Configure' with the resource 'burst behavior' and names the three modes (N-cycle, infinite, gated), which clearly identifies the tool's function. It distinguishes from sibling tools like configure_modulation and configure_sweep because it is specifically for burst, though it does not mention channel scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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, no prerequisites, and no conditions. It only states what it configures, leaving the agent without direction on selecting it over other configuration tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=false and destructiveHint=false. The description adds the concept of 'guarded' destructive and raw output commands, which is useful behavioral context not present in annotations. However, it does not explain what happens when a guarded command is attempted or how confirm_unsafe influences behavior, so transparency is only partially improved.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, immediately front-loaded with the main action. It is concise and free of redundant filler, though the vague terminology slightly reduces its efficiency.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool sends arbitrary SCPI commands to an instrument and has a safety guard, the description is too sparse. It omits the meaning of confirm_unsafe, what commands are considered protected or destructive, and the behavior when a guarded command is sent. The presence of an output schema does not compensate for these operational gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain either parameter. 'command' and 'confirm_unsafe' are left completely undefined; the description mentions protection but not how the confirm_unsafe flag relates to it. No value is added beyond the parameter names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies the action as 'Send a protected setting command,' which conveys a verb and resource, but 'protected' and 'guarded' are vague and do not clearly distinguish it from other write_scpi tools. It does not specify what kinds of commands are allowed or blocked, leaving purpose only partially clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not explicitly state when to use this tool versus query_scpi or other write_scpi variants. It hints that destructive and raw output commands are guarded, but does not say when to use alternatives or how to handle guarded commands, offering no concrete usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate the tool is neither read-only nor destructive, but the description does not disclose side effects, whether changes apply immediately, or what happens to existing sync settings. 'Configure' implies mutation but provides no behavioral depth.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no filler, front-loaded with the action. However, it is too brief and omits critical detail, making it efficient but under-specified.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 3-parameter configuration tool with undocumented parameters, the description is incomplete. It does not explain how to invoke it correctly, what the parameters control, or what the output represents, leaving the agent without enough context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 3 parameters with no descriptions and 0% schema coverage. The description does not mention 'mode', 'enabled', or 'polarity', nor does it hint at valid values or effects. The agent cannot infer parameter meaning from the text.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly specifies the action ('Configure') and the resource ('front-panel TTL Sync connector'), and adds the waveform relationship. It is distinguishable from siblings by the sync connector focus, though it does not elaborate on what configuration outcomes are possible.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives, when not to use it, or what prerequisites or related tools are relevant. The description simply states the purpose without situational context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds the '20 MHz waveform-rate limit' constraint, which is useful behavioral context beyond the annotations. However, it does not disclose side effects like whether existing waveforms are overwritten or how the instrument state changes, and annotations only indicate non-read-only behavior without further detail.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, concise and front-loaded with the primary actions. However, the ambiguous 'Upload/select' phrasing slightly reduces its efficiency, but overall it maintains brevity without unnecessary content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool combines multiple operations (upload/select and set frequency) and has sparse annotations and zero schema description coverage, the description is too brief. It lacks details on parameter semantics, return value behavior, what 'configure' entails, and why this tool exists alongside more granular sibling tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate for parameter meaning. It indirectly references 'ARB data' (values) and 'set frequency' (frequency_hz), but does not explain the 'start' parameter, value formatting, units, or any constraints beyond the rate limit. This is insufficient for full parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool uploads/selects ARB data and sets frequency, which identifies the resource and actions. However, 'Upload/select' is ambiguous, and sibling tools like afg2125_upload_arbitrary_waveform and afg2125_select_arbitrary_waveform already cover these individual actions, so the exact role of this combined tool is not clearly differentiated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance is given on when to use this tool versus calling the separate upload, select, and set-frequency tools. The description does not mention alternatives or exclusions, leaving the agent to infer usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations show readOnlyHint=false, so it's a mutating operation. The description confirms it changes device state but adds no details about side effects, required output state, or whether it resets other settings. With no annotation support, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The single sentence is concise and front-loaded with the key action. It contains no filler, but it lacks any structural breakdown for the five parameters. Still, it earns its place as a brief purpose statement.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 5 parameters with no schema descriptions and only a terse one-liner, the description is incomplete for a configuration tool. It doesn't cover required parameters, spacing options beyond linear/log, or side effects. The output schema exists but doesn't reduce the need for parameter context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate, but it only hints at linear/logarithmic spacing. It doesn't explain start_frequency_hz, stop_frequency_hz, sweep_time_s, or source. The description adds minimal meaning over the bare parameter names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear action ('Enable and configure') on a specific resource ('frequency sweep') and distinguishes it from sibling modulation configs like AM/FM/FSK. The mention of linear/logarithmic adds specificity, but 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.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives such as set_sweep_enabled or configure_am. The context is implied but not stated, and there are no exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With all annotations set to false, the description carries the full burden of behavioral disclosure. It doesn't describe side effects, device state changes, or constraints like whether the instrument must be connected or if gated mode requires specific polarity. It only loosely implies that configuration changes are applied.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no redundancy, making it concise and front-loaded. However, given the tool's complexity (7 parameters), the brevity veers toward under-specification rather than efficient clarity, but it still earns a high score for structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 7 parameters with no schema descriptions, no annotations, and no parameter details in the description. The one-sentence description is inadequate to fully understand the tool's purpose, parameters, and effects, especially in a device-control context where output schema is present but not described.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds minimal meaning beyond the parameter names by hinting that 'mode' can be 'triggered' or 'gated' and that 'source' likely refers to trigger_source. However, it doesn't explain cycles, period_s, gate_polarity, phase_degrees, or how these parameters interact. With 0% schema coverage, this is insufficient.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool configures burst parameters and their source for the Agilent 33500B, distinguishing it from sibling configure tools like configure_pulse or configure_sweep. It specifies the burst mode scope ('triggered or gated') and mentions the source, though it doesn't elaborate on what 'source' specifically refers to.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 other configuration tools, such as set_mode_enabled or configure_sweep. It doesn't mention prerequisites, typical workflow, or whether this should be called before enabling burst.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are all false, providing no safety profile, and the description does not disclose potential side effects, whether a previous connection is replaced, or what happens on failure. The description adds no behavioral context beyond the basic action of connecting.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler words. It is concise, but slightly underwhelming given the tool's six parameters and lack of parameter documentation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given six optional parameters, no parameter descriptions, and all-false annotations, the description is too brief to be complete. It omits important context about connection behavior, prerequisites, or how to know if the connection succeeds, even though an output schema exists.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate, but it only vaguely references 'serial settings that match...front-panel configuration.' It does not explain individual parameters like resource, baud rate, or timeout, though it hints that defaults are derived from the front panel.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Connect') and the target resource ('M8811'), with additional context that it uses serial settings matching the front-panel configuration. It is specific enough to distinguish this from other operations, though it does not explicitly contrast with sibling connect tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives, such as 'use before issuing M8811 commands' or 'use only if not already connected.' The context is only implied by the tool name and the word 'connect'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are all false (readOnlyHint=false, destructiveHint=false, etc.), so the description carries the full burden. It says 'configure' implying a write operation, but it does not disclose whether the sweep is immediately enabled, whether it modifies existing output settings, or any side effects. The phrase about sweep types adds a small behavioral hint but not enough.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no filler, making it concise and front-loaded. However, it is under-specified, but conciseness is about efficiency of prose, and this is efficient albeit too brief.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 8 parameters, 3 required, and no schema descriptions, a one-sentence description is insufficient for an agent to correctly invoke the tool. The output schema exists, so return value details are covered elsewhere, but parameter semantics, ordering, and interaction between start/stop frequency and spacing are left unaddressed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It only hints at the 'spacing' parameter via 'linear, logarithmic, or stepped' but leaves the other seven parameters unexplained (e.g., start/stop frequency, sweep time, direction, trigger source). This is minimal value added over the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool configures a frequency sweep and lists the three supported types (linear, logarithmic, stepped). It distinguishes from other configure_* tools on the same instrument (modulation, burst, sync) by naming the sweep resource. It doesn't differentiate from sweep tools on other instruments, but the tool name provides that context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool vs alternatives, such as whether to use this before enabling the output or how it interacts with set_waveform. No exclusions or prerequisites are mentioned. This is a lack of any usage direction, warranting a score of 2.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With all annotations set to false, the description carries the burden of disclosing behavior. It mentions 'with read-back' which hints at a return value, but it does not explain whether unspecified parameters are reset or preserved, whether validation occurs, or what the read-back contains. This is a significant gap for a tool with many optional parameters.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that front-loads the action ('Set') and enumerates the key parameters. Every word contributes, with no redundant or irrelevant content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of 8 parameters and no annotation support, the description is incomplete. It does not address how the multiple optional parameters interact, whether partial updates are supported, or any preconditions. An output schema exists, so return details are covered, but usage and behavioral context are still lacking.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It lists the parameter concepts (duty, symmetry, phase, etc.) but without explaining units, constraints, or relationships (e.g., edges map to rise_s/fall_s). The schema property names are already descriptive, so the description adds minimal semantic value beyond restating them.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool sets specific waveform parameters (duty, symmetry, phase, pulse width, edges, delay) on a channel, using the verb 'Set'. It is specific enough to distinguish from sibling tools like 'set_waveform' by listing detail parameters, though it does not explicitly mention alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 other set/configure tools. It does not mention prerequisites (e.g., waveform type that supports these parameters) or exclusions (e.g., basic waveform setup should use set_waveform).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are all false, providing no safety or side-effect hints. The description adds only the vague phrase 'frequency-dependent manual limits,' which is ambiguous and does not disclose what happens on invalid input, whether limits are enforced, or how they are determined. This leaves significant behavioral ambiguity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no redundant information. It front-loads the primary action and includes one qualifier, but it is efficiently structured. Could be slightly more informative without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple setter tool, a minimal description is acceptable, but this one omits critical details: the allowed range for duty_percent, how frequency-dependent limits are handled, and any prerequisites (e.g., device must be connected, square wave must be active). The output schema may define return values, but it is not provided, so the description alone is insufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% for the single parameter 'duty_percent', so the description must compensate. It states the parameter sets a square-wave duty cycle, which is some meaning, but it fails to specify range (e.g., 0-100), units, or the nature of the frequency-dependent limits it mentions. This is insufficient for correct invocation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool sets a square-wave duty cycle, using a specific verb ('Set') and resource ('square-wave duty cycle'). It distinguishes from sibling tools like afg2125_set_ramp_symmetry or afg2125_set_function by naming the exact parameter and waveform type.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not specify when to use this tool vs. alternatives, nor does it mention any exclusions or alternative tools. The phrase 'frequency-dependent manual limits' hints at constraints but does not explain how to apply them or when this tool is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds the behavioral precondition that the output must be disabled, which is useful beyond the annotations (readOnlyHint=false, etc.). It does not disclose side effects or whether existing settings are overwritten, but it gives a meaningful operational constraint.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that efficiently conveys the core purpose and the key precondition. It is not overly verbose, though it sacrifices substance for brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 4 parameters, no schema descriptions, and a sibling tool for detailed waveform setup, the description is too sparse. It does not clarify what a 'standard waveform' entails or how to choose between this and set_waveform_detail, making it inadequate for reliable usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description says nothing about the parameters (function, frequency_hz, offset_volts, amplitude_vpp), and the schema has 0% coverage. The agent has no guidance on valid values, units, or defaults. This is a critical gap for correct invocation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool configures a standard waveform and includes the condition that the output is disabled. It is specific enough to distinguish from simple get/set operations but does not explicitly differentiate from the sibling agilent33500b_set_waveform_detail.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'while the channel output is disabled' provides a clear contextual constraint, implying the tool should be used before enabling the output. However, it does not explicitly mention when to use this versus set_waveform_detail or other alternatives, so guidance is limited.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate this is not read-only and not destructive by default. The description adds context that destructive and raw output commands are 'guarded', implying a confirmation mechanism. However, it does not explain what happens when a guarded command is sent without confirmation, so the added transparency 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.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no superfluous words. It communicates the core function and a safety constraint efficiently. However, it is slightly under-specified, but for conciseness and structure it earns a 4.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema, the description lacks essential context for a raw SCPI write tool. It does not explain the command format, the nature of the safety guard, or how errors are reported. This is insufficient for an agent to safely invoke the tool, especially given the destructive/raw output guard.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description must compensate for parameter meaning. It mentions 'destructive and raw output commands are guarded', which indirectly relates to confirm_unsafe, but it does not explain that command takes a SCPI string or when confirm_unsafe should be true. The parameter names are somewhat self-explanatory, but the description adds little beyond them.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb+resource: 'Send a protected setting command'. It distinguishes from the sibling query tool by mentioning 'setting' versus the query tool's purpose, though it does not explicitly say 'write SCPI'. The name reinforces this, but the description itself is somewhat vague about what counts as a 'protected setting command'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no explicit guidance on when to use this tool versus alternatives like agilent33500b_query_scpi. It hints at safety (guarding destructive/raw output) but does not state when to send such commands or that confirm_unsafe should be set to true. No clear context for selection is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description says 'Read' which implies a read-only operation, but the annotation readOnlyHint is false, indicating the tool may not be read-only. This is a direct contradiction. Additionally, no other behavioral details (e.g., error handling, state changes) are disclosed, and the false annotations fail to clarify side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that immediately conveys the core function without any redundant wording. It is appropriately sized for the tool's apparent simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema, the description omits critical context such as required instrument connection, possible measurement types, and behavior when parameters are invalid. The annotation contradiction further undermines completeness, making this insufficient for reliable agent use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description must compensate but only partially explains the channel parameter by mentioning CH1/CH2. The measurement parameter is entirely unaddressed; no valid values or default behavior beyond schema defaults are described, leaving the agent to guess what measurements are supported.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool reads an immediate measurement from CH1 or CH2, with a specific verb ('read'), resource ('measurement'), and channel scope. It distinguishes itself from waveform acquisition or SCPI commands by specifying the immediate measurement nature.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives like agilentdsox2012a_acquire_waveform or agilentdsox2012a_query_scpi. The description implies a direct one-shot measurement but does not explain suitable scenarios, prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations give no meaningful safety signals (all hints false), so the description carries the transparency burden. It does disclose the 'after confirmation' gating behavior and the protocol format, which is useful. However, it does not explain side effects, what happens without confirmation, or error handling.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with a front-loaded verb, making it efficient. However, 'documented' is filler and the terseness contributes to ambiguity rather than clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a write tool with 3 parameters and no schema descriptions, this is under-specified. Missing details include the meaning of command_prefix, how to construct data_base64, whether confirmation is required, and any return/error behavior. The output schema does not compensate for these gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description must compensate, but it only vaguely maps to data_base64 via 'binary block' and confirm_binary_write via 'after confirmation'. The command_prefix parameter is completely unexplained, and there are no details about base64 encoding or block format syntax.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Send' and identifies the resource as a 'definite-length binary block' following IEEE-488.2, which clearly distinguishes it from sibling tools like write_scpi or query_binary. However, the word 'documented' is vague and doesn't clarify what the binary block represents or why it is documented.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 agilentdsox2012a_write_scpi or agilentdsox2012a_query_binary. The description offers no context about prerequisites, typical scenarios, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds some behavioral context beyond annotations by mentioning 'protected' and 'unsafe commands require an environment opt-in'. However, it doesn't specify what makes a command unsafe, what the environment opt-in is, or what happens if an unsafe command is sent without it, leaving ambiguity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that front-loads the action. It avoids waste but the vagueness ('protected', 'unsafe') makes it less useful than it could be; still, it is well-structured and brief.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool that sends arbitrary SCPI commands, the description is incomplete. It doesn't mention return behavior, error handling, the relationship between confirm_unsafe and the environment opt-in, or the scope of 'protected' commands. Even with an output schema, the safety and command constraints are not clarified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain the 'command' or 'confirm_unsafe' parameters. The mention of 'environment opt-in' is confusing because the schema has a 'confirm_unsafe' boolean, but the description does not connect them, failing to compensate for the lack of schema detail.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Send') and resource ('a protected DSO-X setting command'), clearly indicating it writes SCPI commands to the oscilloscope. It distinguishes from query_scpi by implying settings vs queries, but doesn't explicitly differentiate from agilentdsox2012a_command or write_binary.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives like agilentdsox2012a_query_scpi or agilentdsox2012a_command. The 'protected' hint implies some use cases but there is no clear context, exclusions, or alternative recommendations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are all false and provide minimal positive context, so the description carries the burden of explaining side effects. It states that list behavior is configured but does not disclose persistence, whether existing settings are overwritten, or whether operation is reversible. The mutation implication is consistent with readOnlyHint=false, but the lack of behavioral detail is a gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with a leading verb and concise object list. Every word contributes meaning, and there is no redundant repetition of the tool name or schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has three optional parameters with no enums and no schema descriptions, and the description provides no values, defaults, or interactions with sibling tools. Although an output schema exists, the description still lacks sufficient context about the effect of configuring these options and how the tool relates to other list-management functions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With schema description coverage at 0%, the description compensates partially by suggesting that 'memory partition', 'step count', and 'continuous/step/loop behavior' correspond to the parameters area, count, and mode respectively. However, it does not explicitly map parameters to schema fields or explain allowed modes or count ranges, leaving ambiguity for a three-parameter tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific action ('Configure') and specific resources ('LIST memory partition, step count, and continuous/step/loop behavior'), which gives a clear sense of the tool's scope and distinguishes it from sibling tools like m8811_set_list_step or m8811_recall_list. It is not a tautology and is more specific than a generic verb, though 'configure' is less precise than 'set' or 'enable'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 alternatives such as m8811_set_list_step or m8811_set_mode. There is no mention of prerequisites, exclusions, or preferred use cases, despite several related sibling tools existing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are all false, offering no safety profile. The description only says 'Select', but does not disclose side effects on the instrument, whether settings are changed, what happens with invalid inputs, or the 'safe' validation behavior. With no annotation support, the description fails to provide behavioral context beyond the basic action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that effectively communicates the core action without wasted words. It is concise and well-structured for quick parsing, though it omits necessary detail that would reduce the score further.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema, the tool involves selecting a waveform with multiple optional parameters and side effects on an instrument. The one-sentence description does not cover selection semantics, parameter interactions, error handling, or what happens to the instrument state. It is not complete enough for an agent to use without external knowledge.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description gives only a vague mapping: 'built-in ARB index' to 'index' and 'safe user waveform name' to 'name'. It does not explain the required 'channel' parameter, how to choose between index and name, or what happens if both/neither are provided. The description does not compensate for the schema's lack of semantic detail.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Select' and identifies the resource as 'built-in ARB index or one safe user waveform name', making clear this selects an arbitrary waveform on the instrument. It distinguishes from siblings like 'upload_arbitrary_waveform' by implying an existing waveform selection, though it doesn't fully clarify what 'safe user waveform name' means.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use this tool: to select an arbitrary waveform by index or name, rather than upload or configure one. However, it provides no explicit when/when-not guidance or references to alternatives like set_waveform or upload_arbitrary_waveform, leaving the decision partially to the agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are all false and provide no safety profile. The description adds one useful behavioral fact: ASK/PSK/DSB-AM ignore the 'amount' parameter. However, it does not disclose other important behaviors like default modes, validation rules, or response handling, leaving much of the burden unmet.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is front-loaded with the core action ('Configure modulation') and immediately adds a relevant caveat. Every word earns its place; there is no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having 7 parameters and an output schema, the description is extremely sparse. It does not explain what modes are available, what the default mode is, how the parameters interact, or what the output response indicates. The description is adequate only for the 'amount' edge case, leaving overall operation poorly specified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 7 parameters with 0% description coverage. The description only clarifies the 'amount' parameter for ASK/PSK/DSB-AM modes, leaving 'mode', 'source', 'enabled', 'modulation_wave', 'modulation_frequency_hz', and 'channel' completely undocumented. This minimal compensation is insufficient for the parameter count.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Configure' with the resource 'modulation', clearly indicating the tool's function. It distinguishes from sibling tools like configure_sweep and configure_burst by name, though it does not enumerate the supported modulation modes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus the many sibling configuration tools. The phrase 'Configure modulation' only restates the purpose without providing context, prerequisites, or alternative recommendations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The phrase 'with model capability checks' hints at a preflight validation, but the description does not disclose behavior for unsupported models, whether existing settings are overwritten, or the effect on device state. Annotations are all false and carry no informative value, so the burden falls on the description, which fails to provide adequate transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no filler or redundant information. It is front-loaded with the verb and resource, making it easy to scan and understand.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with six parameters and zero schema-level descriptions, this description is incomplete. It lacks units, allowed values for source and internal_function, the role of 'enabled', and how parameters interact. An output schema exists but does not compensate for the missing parameter semantics.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaning only to the 'mode' parameter by listing valid values (AM, FM, PM, PWM, FSK, BPSK, SUM). The other five parameters (amount, source, enabled, internal_function, internal_frequency_hz) remain undocumented. Since schema description coverage is 0%, the description heavily under-delivers on parameter explanation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function with a specific verb ('Configure') and explicitly lists the supported modulation types (AM, FM, PM, PWM, FSK, BPSK, SUM). It distinguishes itself from sibling tools like set_waveform and set_mode_enabled by targeting modulation configuration.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 such as agilent33500b_set_mode_enabled or configure_sweep. It implies usage for configuring modulation but lacks explicit exclusions, prerequisites, or comparative context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds behavioral context beyond annotations by explaining the read/write distinction via the query parameter and noting that writes are protected by an unsafe-command policy. However, it does not describe what that policy entails (e.g., confirmation, error behavior), leaving a gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loads the core purpose, and avoids irrelevant details. It is appropriately compact.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity and existing output schema, the description covers the essential purpose and read/write behavior, but it lacks details on the unsafe-command policy and error/return specifics. It is adequate but relies on external knowledge of dpo2012b_write_scpi.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With zero schema description coverage, the description must explain parameters itself. It does clarify query's meaning and role, and implicitly references confirm_unsafe through the write-protection policy, but it does not explain confirm_unsafe's exact behavior or the command string format beyond inferable examples.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function as executing any text SCPI command for the DPO2012B, using the specific verb 'Execute' and a defined resource scope. It distinguishes itself from sibling tools by covering both read and write operations via the query parameter, though it does not explicitly name alternative tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The only guidance is to set query=true for read-only queries, which addresses a parameter choice rather than a tool-selection decision. There is no explicit statement about when to prefer this tool over dpo2012b_query_scpi or dpo2012b_write_scpi, nor when to use dedicated setter tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds a behavioral note that destructive commands require explicit confirmation, which is useful beyond the annotations (destructiveHint=false). Yet it does not disclose other behaviors such as return values, error handling, or whether the tool is a raw passthrough. The annotation and description do not contradict; they complement each other.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with two well-separated clauses. It is concise and front-loaded, with no wasted words, though it could have included more detail without losing brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple SCPI write tool, the description is minimal but not complete. It does not explain what the tool returns (despite having an output schema), does not distinguish it from the sibling 'dpo2012b_command', and omits prerequisites like device connection. The confirmation hint is the only extra context beyond the schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It only indirectly references confirm_unsafe ('destructive commands require explicit confirmation') but does not explain the command parameter format, possible values, or any additional constraints. This is insufficient for a zero-coverage schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool sends a SCPI setting command, which is a specific verb+resource. However, it does not differentiate from the sibling 'dpo2012b_command', which likely serves a similar raw SCPI command role, so it loses a point.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'setting command' implies it is for write operations rather than queries, and the warning about destructive commands needing confirmation gives some usage context. However, it does not explicitly say when to use this tool over alternatives like query_scpi or command, nor does it provide exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are all false, providing no safety or behavioral hints. The description does not disclose side effects, such as how the enabled flag affects the device, whether settings persist, or any interaction with other sync-related settings. It only states the action without 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.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is direct and front-loaded with the verb 'Configure'. There is no redundant or unnecessary information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema, the description is minimal and does not cover the behavior of `enabled`, the meaning of source channel selection, or any setup requirements. With no annotations, this leaves significant gaps for a mutation tool, making it only minimally complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must clarify parameters. It mentions 'source channel' but does not explain the `enabled` parameter or its role. The `source_channel` is only loosely referenced as 'source channel' without details on allowed values or meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool's function: configuring the rear Aux In/Out CMOS Sync output and source channel. It uses a specific verb and resource, distinguishing it from other sdg1062x configuration tools like configure_modulation or configure_sweep.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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, and there are no explicit exclusions or prerequisites. The agent must infer from the name and description that this is for sync configuration, which is implicit at best.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are all false, so the description must disclose behavior. It adds the prerequisite but doesn't explain side effects or what happens if the condition is not met. It also doesn't clarify how configuration interacts with existing settings.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
One sentence with no filler. The prerequisite is integrated efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with four unannotated parameters and no schema descriptions, the description is too sparse. It doesn't define the parameters or discuss behavior when expectations aren't met.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage and the description doesn't mention any parameters. It offers no explanation of source, depth_percent, modulation_function, or modulation_frequency_hz beyond their names and defaults.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Enable and configure' with resource 'AM', clearly indicating the tool sets up AM modulation. It is distinct from sibling tools like set_am_enabled, though it doesn't explicitly call them out.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It states a prerequisite: 'MAIN output must already be disabled.' This gives clear context for when to use the tool. However, it doesn't mention alternatives or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide minimal safety info (all false). The description adds no details about side effects, precedence between width and duty, units, or whether changes take effect immediately. For a mutation tool, this is a notable gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence that front-loads the core purpose. It uses no filler words and is appropriately sized for a simple configuration tool, even though it sacrifices depth.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 5 optional parameters and no required fields, plus a 0% schema description coverage, the description lacks essential context: parameter precedence, dependencies (e.g., pulse mode must be enabled), and how the tool interacts with sibling configuration tools. This is insufficient for reliable autonomous use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description partially compensates by grouping parameters into period, width/duty, and edge transition times. However, it does not explain the relationship between width and duty (likely alternatives) or clarify that leading/trailing are transition times, leaving ambiguity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool configures pulse parameters: period, width or duty, and edge transition times. This is a specific verb-resource combination and distinguishes it from sibling tools like configure_sync or configure_burst.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives like set_waveform or set_waveform_detail. It does not mention prerequisites (e.g., pulse mode enabled) or exclusions, leaving the agent to infer usage from the name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds no behavioral details beyond the annotations. It doesn't disclose error behavior if already disconnected, whether it is safe to call multiple times (idempotency), or what side effects occur (e.g., releasing resources). The annotations indicate destructiveHint=false but closing a session has resource implications.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
One short, front-loaded sentence that conveys the essential action. Every word earns its place; no wasted information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter disconnect operation, this is minimally adequate. However, it could mention usage context (e.g., call after finishing measurements) and behavior when the session is already closed, which are missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the schema provides full coverage. Per the rubric, a baseline score of 4 applies; the description doesn't need to add parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Close') and the resource ('DSO-X 2012A VISA session'), which is specific to this instrument. It distinguishes from sibling disconnect tools by naming the instrument, though it largely restates the tool name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to call this tool, such as after measurements are complete or before exiting. It does not mention alternatives or exclusions, leaving the agent to infer usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safe read nature is known. The description adds the key behavior that the response is Base64-encoded binary data and that the query must be documented, but it does not disclose error behavior or prerequisites like an active connection.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one concise, front-loaded sentence with no filler. Every phrase contributes meaning: it states the action, the object, and the output format.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Although the tool has an output schema and only one parameter, the description alone is insufficient for reliable invocation. It lacks command examples, accepted query syntax, and usage context, making it incomplete for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description must compensate for the 'command' parameter. It hints that 'command' is a binary query, but it does not specify the command format, allowed values, or syntax, leaving a significant gap for the agent.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Run') and identifies a distinct resource ('documented binary query'), plus specifies the return format (Base64). This distinguishes it from sibling tools like dpo2012b_query_scpi, though 'documented' is somewhat vague.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'binary query' implies this tool is for binary requests rather than textual SCPI queries, and the sibling dpo2012b_query_scpi is an evident alternative. However, there is no explicit guidance on when to choose this over the text query tool or what counts as a 'documented' query.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are all false, meaning no safety hints are given. The description adds the key behavioral constraint that this only works while output is disabled, which is useful. However, it does not disclose potential side effects, prerequisites (e.g., whether the mode must be configured first), or error behavior. This is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The single sentence is concise and front-loaded with the action. Every word adds value, stating what the tool does and an important condition. No filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Although the tool is simple and has an output schema, the complete lack of schema descriptions places a burden on the description to explain all parameters. It only covers the mode values and the output-disabled condition, leaving channel and enabled semantics unexplained. This is a clear gap for a 3-parameter tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It partially does by listing the possible mode values ('modulation, sweep, or burst'), but it does not explain the 'channel' parameter or the 'enabled' boolean beyond the verb 'Enable or disable.' With three required parameters and no schema descriptions, this is insufficient.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool enables or disables modulation, sweep, or burst modes, with a specific condition 'while output is disabled.' It uses a specific verb and resource, and lists the three mode types. However, it does not explicitly differentiate from sibling configuration tools like sdg1062x_configure_modulation, so it falls 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.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear usage condition (output must be disabled) but gives no guidance on when to use this tool versus alternatives like sdg1062x_configure_modulation, sdg1062x_configure_sweep, or sdg1062x_configure_burst. The context is implied rather than explicit, so it earns a 3.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are all false, offering no behavioral hints, so the description carries the burden. It adds context like 'guarded' and 'armed' but does not explain what these mean or possible side effects, such as output changes or errors if not armed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no redundant wording. It is front-loaded and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With three parameters, a 0% schema description coverage, and an existing output schema, the description is too sparse. It omits prerequisites, parameter meanings, and behavior, leaving significant gaps for an agent trying to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description does not clarify the meaning of 'channel', 'mode', or 'confirm_trigger'. It only hints that the tool relates to sweep or burst, which is insufficient for understanding how to set parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Send') and resource ('manual trigger to an armed sweep or burst'), clearly distinguishing it from sibling tools by referencing the armed state. It is clear but could be more explicit about instrument-specific details.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when a sweep or burst is armed, but provides no explicit when-to-use guidance or alternatives. It does not mention when not to use it or prerequisites like prior configuration.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide no safety hints (all false), and the description only says 'configure,' which implies a write operation but gives no details about side effects, prerequisites, or impact on other settings. It does not disclose whether enabling sweep disables burst or modulation, or any other behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no unnecessary words. It front-loads the core action and parameters, making it highly efficient and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 7 parameters, 2 required, and zero schema coverage, the description is far too brief. It fails to explain the meaning of start/stop frequencies, sweep time, or the 'enabled' flag, and does not mention any constraints or relationships between parameters. The output schema may help, but the description itself is inadequate for an agent to confidently use the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It mentions spacing, trigger source, and marker, but leaves start_frequency_hz, stop_frequency_hz, sweep_time_s, and enabled unexplained. The description does not even clarify that start/stop frequencies are required or their units, making it insufficient for correct invocation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('configure') and resource ('sweep'), and explicitly mentions key aspects like linear/log spacing, trigger source, and optional Sync marker. This clearly distinguishes it from sibling tools such as configure_burst or configure_modulation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for sweep configuration but does not explicitly state when to use this tool over alternatives like configure_burst or configure_modulation. There is no mention of prerequisites or when not to use it, leaving the agent with only the tool name and minimal context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds context beyond the annotations by using the word 'guarded' and specifying the precondition 'armed sweep or burst.' However, it does not explain the effects of triggering, potential errors, or the purpose of the confirm_trigger parameter. Given that annotations already indicate a non-read-only, non-destructive action, the description provides moderate additional behavioral context but not deep transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that immediately states the action and target. It contains no filler or redundant information, making it efficient and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has one parameter and an output schema, but the description leaves the parameter completely unexplained. While the core trigger action is clear, the missing parameter semantics creates a significant gap for an agent trying to correctly invoke the tool. The description is not complete enough for a tool with a non-obvious parameter.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description does not mention the sole parameter, confirm_trigger, which is a boolean with a default of false. The schema also lacks a description for this parameter (schema_description_coverage is 0%). Since the parameter is not self-explanatory (it likely requires confirmation before triggering), the description fails to compensate for the missing schema information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'Send a guarded IEEE-488 bus trigger' and specifies the target: 'to an armed sweep or burst.' This uses a specific verb and resource, and distinguishes it from sibling tools like agilent33500b_configure_sweep or agilent33500b_set_waveform, which configure rather than trigger.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool by referencing 'an armed sweep or burst,' indicating the tool is for triggering after arming. However, it does not explicitly mention alternatives (e.g., using agilent33500b_write_scpi to send a *TRG command) or conditions when the tool should not be used, such as when no sweep/burst is armed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are all false (no safety hints), so the description carries the burden. It adds only the transport types and does not disclose whether the connection is stateful, what side effects occur (e.g., opening a session), whether the device must be physically present, or what error/failure behavior to expect. This is minimal for a connection operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence with no redundant words. It is front-loaded with the core purpose and lists the interfaces efficiently. It earns its place entirely.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has two parameters, no annotation support, and an output schema we don't see, the description leaves major gaps: it doesn't mention what the function returns, what 'resource' should look like, or how 'timeout_ms' affects behavior. It is too bare to fully guide an agent in using the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It indirectly hints at 'resource' via the supported interfaces, but it does not explain the meaning of 'timeout_ms' at all, nor does it clarify the format of 'resource' (e.g., address string). With two parameters and no descriptions, this is insufficient.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Connect' and names the exact resource (Agilent/Keysight DSO-X 2012A) plus the supported interfaces (USBTMC, LAN, GPIB). This clearly distinguishes it from sibling connect tools for other instruments.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool should be used to establish a connection to this oscilloscope before issuing other commands, but it does not explicitly state when to use it versus connecting to other devices or mention any preconditions or alternatives. The context is clear from the name and description, but no exclusions or alternative references are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds no behavioral information beyond what the annotations already provide. It repeats the readOnlyHint as 'read-only' without disclosing any additional traits such as whether a response is expected, timeouts, or error behavior. Given the annotations already declare safety, the description contributes little.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one short sentence, free of fluff, and front-loads the key information. It is appropriately concise for a simple tool, though a slight expansion would improve clarity without hurting conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (1 parameter), existing annotations, and output schema, the description is minimally adequate. It tells the agent this is a read-only SCPI query for a specific device, but leaves out context about command syntax and return behavior, which the output schema may not fully cover.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter 'command' has no schema description and the description does not explain what constitutes a valid SCPI command or provide examples. With 0% schema coverage, the description should compensate but instead offers no guidance on formatting or expected syntax.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Send' with a clear resource 'DSO-X 2012A SCPI query' and explicitly marks it as 'read-only', distinguishing it from the sibling write_scpi tool. It clearly identifies the device and the operation type, avoiding any ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The 'read-only' qualifier implies this is for querying rather than writing, but no explicit guidance is given on when to use this versus alternatives like the device-specific measure or acquire_waveform tools. There is no mention of when not to use it or mention of higher-level abstractions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds useful context about data formats and channels, but with all annotations false, it bears the full burden of disclosing side effects. It does not explicitly state whether this operation modifies instrument state or is purely a read, leaving some ambiguity. 'Acquire' implies a read-like operation, but the description does not confirm safety or reversibility.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no redundant words. It front-loads the core action and includes only essential qualifiers (formats and channels), making it highly scannable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has six optional parameters and an output schema, but the description provides only a minimal overview. It omits parameter semantics, usage guidance, and any description of return behavior, which is insufficient for an agent to invoke the tool correctly in complex scenarios.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% and the description only indirectly mentions 'ASCII or IEEE-488.2 binary' (encoding) and 'CH1 or CH2' (channel). It provides no explanation for start, stop, width, or max_points, which are all optional but meaningful parameters. The agent would have to infer their semantics from the schema alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Acquire'), the object ('scaled ASCII or IEEE-488.2 binary waveform points'), and the scope ('from CH1 or CH2'). This is specific and distinct from sibling tools like measure or capture_screenshot.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 such as dpo2012b_measure or dpo2012b_query_binary. It does not mention prerequisites, exclusions, or context that would help an agent choose this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are all false, providing minimal safety context, and the description does not disclose behavioral aspects such as whether the measurement triggers a state change, blocks, or returns data. The word 'immediate' hints at an action but lacks detail about side effects, errors, or prerequisites. The output schema covers return values, but the behavior beyond that is opaque.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one focused sentence, front-loaded with the action and context. Every word contributes to understanding the tool's core purpose, with no wasted information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite an output schema, the description fails to provide necessary context for a measurement tool: no guidance on measurement parameter choices, no mention of when to use it vs. alternatives, and no behavioral details. The tool is simple but leaves the agent uncertain about the 'measurement' parameter and the operation's side effects.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It mentions 'CH1 or CH2' for the channel parameter, but the measurement parameter is not elaborated at all, leaving valid values (e.g., FREQUENCY, other measurement types) undocumented. This is insufficient for a 2-parameter tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Take' and clearly identifies the resource (DPO2012B measurement) and scope (CH1 or CH2). It distinguishes itself from sibling tools like dpo2012b_acquire_waveform and dpo2012b_get_channel_settings by focusing on immediate measurement, not waveform acquisition or channel settings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for quick, single measurements on a specific channel via 'immediate,' but it does not explicitly state when to use this tool versus alternatives like dpo2012b_acquire_waveform or how it relates to other measure tools. There are no exclusions or alternative references.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are all false, providing minimal safety profile. The description adds the behavioral detail of 'carrier/deviation limit checks', but does not explain what happens on failure (e.g., error vs. clamping) or whether settings are overwritten. This is some value beyond annotations 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.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence that is front-loaded with the main action and contains no filler. Every word adds value, making it highly concise and scannable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 4 parameters and an output schema, and the description is quite brief. While the core purpose is covered, missing usage context and parameter semantics make it only minimally complete for an agent to confidently invoke. The output schema mitigates the need for return value explanation, but more detail on configuration behavior would improve it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%: neither the schema nor description explains parameters like source, deviation_hz, modulation_function, or modulation_frequency_hz. The description's mention of 'deviation limit checks' hints at deviation_hz but does not clarify units, ranges, or relationships. With zero coverage, the description fails to compensate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Enable and configure FM with carrier/deviation limit checks.' This uses a specific verb (configure) and resource (FM), and the mention of limit checks distinguishes it from simpler toggles like set_fm_enabled and from AM/FSK configurations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use guidance is provided. It does not mention alternatives such as afg2125_set_fm_enabled for simple toggling, nor when not to use this tool. The context of siblings is not leveraged to direct the agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description reveals that APPLy, OUTPut, and destructive commands are guarded, which adds safety context beyond the annotations (all false). This helps the agent understand that these commands require extra care, likely via confirm_unsafe. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, highly concise, and front-loaded with the primary action. Every word adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While the output schema may define return values, the description is too brief to cover critical behavior: the exact meaning of 'guarded', the consequence of attempting a guarded command without confirmation, and the expected command format. For a low-level SCPI tool, this leaves significant gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema provides no descriptions (0% coverage), and the description only indirectly references the confirm_unsafe parameter by saying certain commands are guarded. It doesn't explicitly explain that confirm_unsafe must be set to true for guarded commands, nor does it describe the command parameter format.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Send' and the resource 'setting command', which distinguishes it from query_scpi. However, 'setting command' is somewhat vague and doesn't specify what types of SCPI commands are accepted beyond implying configuration commands.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for sending SCPI setting commands, but it doesn't explicitly contrast it with query_scpi or the high-level setter functions. The mention of guards hints at special treatment for certain commands but no 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.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide no safety hints (readOnlyHint, destructiveHint, idempotentHint are all false), so the description carries the burden of behavioral disclosure. It only says 'Connect,' which implies session establishment but doesn't explain what happens if already connected, whether it's idempotent, or any side effects. This is a significant gap for a connection operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence: 'Connect to an Agilent/Keysight 33500 Series generator over VISA.' It contains no filler or repetition, making it maximally concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple connect function with an output schema and two optional parameters, the description is minimally adequate but lacks context about session lifecycle, relationship to disconnect tools, or parameter semantics. It is not dangerously incomplete, but there are clear gaps that could confuse an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate by explaining the two parameters (resource and timeout_ms). It doesn't mention either, leaving the agent to infer meanings from names alone. No details about VISA resource string format or timeout units are provided, which is insufficient.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Connect' and names the resource 'Agilent/Keysight 33500 Series generator over VISA,' clearly distinguishing it from sibling connect tools for other instruments. This is unambiguous and directly states what the tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this tool is used for connecting to an Agilent 33500 instrument, but it doesn't explicitly state when to use it versus other connect tools, nor mention prerequisites like disconnecting an existing session. No alternatives or exclusions are given, so usage is only implied by the tool name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are all false (readOnlyHint, destructiveHint, etc.), so the description carries the full burden of behavioral disclosure. It mentions 'ASCII transfer' as a detail, but does not disclose side effects, whether it triggers a new acquisition, or any prerequisites. No contradiction with annotations, but the 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.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, tightly worded sentence with no fluff. It front-loads the action and resource while also conveying the transfer method. This is appropriately concise for a simple tool, though additional detail could be added without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is an output schema, so return values do not need to be described in the text. The description states the primary outcome (acquiring scaled waveform points) and the transfer method, but it lacks guidance on parameter usage, when to use it versus alternatives, and any behavioral caveats. For a two-parameter tool, it is minimally complete but leaves gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has 0% description coverage, so the description must compensate. It only clarifies that the channel parameter accepts CH1 or CH2, but gives no detail about 'max_points'—its purpose, range, or effect. The parameter names and defaults provide some clues, but the description adds minimal value beyond them.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Acquire') with a clear resource ('scaled waveform points'), scope ('CH1 or CH2'), and method ('using ASCII transfer'). This clearly differentiates it from sibling tools such as 'measure', 'query_scpi', or other device-specific acquire functions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage context is implied by the tool's purpose but not explicitly stated. The description does not mention when to use this tool instead of alternatives like 'agilentdsox2012a_measure' or 'agilentdsox2012a_query_scpi', nor does it provide exclusions or prerequisites such as requiring a connection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate a non-read-only, non-idempotent, non-destructive operation, and the description adds specific behavioral context by explaining what the mode switch does. However, it does not disclose effects like potential disconnection or the need for confirmation, which could be relevant given the confirm_remote parameter.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that front-loads the core action. It contains no filler and is easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 2 parameters and 0% schema coverage, the description is too brief to be fully complete. It omits the purpose of 'confirm_remote' and does not clarify the implications of the mode switch (e.g., whether the instrument disconnects). The output schema exists but the behavioral context is insufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must explain all parameters. The 'remote' parameter is partially explained through 'guarded PC/front-panel lock mode' vs 'local panel control', but 'confirm_remote' is not mentioned at all. This is an incomplete compensation for the lack of schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: entering guarded PC/front-panel lock mode or returning to local panel control. It uses a specific verb and resource, and distinguishes itself from sibling tools (e.g., m8811_set_voltage, m8811_set_current) by focusing on panel lock mode.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context by describing the two states (remote and local), but does not explicitly state when to use this tool versus alternatives or provide exclusions. It is clear enough for an agent to infer when to invoke, but lacks explicit guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses two behavioral traits beyond the annotations: output is disabled (so the configuration does not immediately apply to the physical output) and the tool performs SCPI read-back (verification). These add useful context about side effects and verification behavior. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that conveys the core action and key behavioral qualifiers. Every word earns its place; no filler or unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that the tool has 5 parameters and no schema descriptions, the description is too sparse to fully guide an agent. It does mention output-disabled safety and read-back, which helps, but it lacks details on parameter semantics and when to use this vs. more advanced waveform configuration tools. The output schema likely covers return values, so no deduction there.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning the parameter properties have no descriptions. The tool description merely says 'Configure a channel waveform' and does not explain what 'function', 'frequency_hz', 'offset_volts', 'amplitude_vpp' mean, their units, or how they map to the instrument. It fails to compensate for the absent schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (Configure) and resource (a channel waveform), and adds specific scope (with output disabled and SCPI read-back). It does not explicitly distinguish this from sibling tools like sdg1062x_set_waveform_detail, so it's clear but not fully differentiated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'with output disabled' implies this is a safe way to configure settings without affecting the actual output, and 'SCPI read-back' suggests it verifies after setting. However, it does not explicitly state when to use this tool versus alternatives like sdg1062x_set_waveform_detail or sdg1062x_set_output, so usage guidance is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description mentions 'with read-back,' which discloses a behavioral trait beyond the annotations. However, it does not explain that some parameters depend on the selected waveform type (e.g., duty cycle only affects square waves) or discuss other side effects. With all annotations false, the description partially carries the burden but leaves gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence that front-loads the key actions and parameters. Every word is purposeful, with no redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description gives the core purpose and read-back, but omits critical operational context such as parameter applicability depending on the active waveform. While the output schema covers return values, the conditional behavior of the settable parameters is not explained, leaving the description incomplete for complex usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description essentially restates the parameter names (duty cycle, symmetry, phase, polarity) without adding units, ranges, or interaction details. Since schema description coverage is 0%, the description should compensate but does not provide meaningful semantic addition beyond the titles.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool sets specific waveform parameters (duty cycle, ramp symmetry, phase, or output polarity) and includes read-back. This distinguishes it from sibling tools like agilent33500b_set_waveform, which focuses on the basic waveform setup.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied by the listed parameters, but the description does not explicitly state when to use this tool vs alternatives or mention any exclusions. It lacks direct guidance on when this tool is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the operation as non-read-only and non-idempotent, aligning with the 'connect' action. The description adds the auto-detection behavior as extra context, but it does not disclose connection lifecycle effects, such as how this affects subsequent dpo2012b_* commands or what happens on failure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that conveys the primary purpose and the key nuance about resource auto-detection. Every word earns its place; there is no redundancy or unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter connect tool with an output schema and annotations, the description covers the core purpose and one behavioral detail. It lacks broader context about the connection lifecycle — for example, that a connection is a prerequisite for other dpo2012b_* tools or how an existing connection is handled — but it remains minimally viable given the low complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description must compensate for parameter meaning. It clarifies the 'resource' parameter by noting auto-detection when omitted, but it provides no guidance on 'timeout_ms' — its units, accepted range, or behavior — leaving a significant semantic gap for one of the two parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource ('Connect to a DPO2012B'), which clearly states what the tool does. The addition 'auto-detect it when resource is omitted' further clarifies the tool's scope, and the device name in the tool name distinguishes it from sibling connect tools for other instruments.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage via the auto-detect clause, indicating the resource parameter can be omitted. However, it does not explicitly state when to use this tool versus alternatives (e.g., other connect tools or list_visa_instruments), nor does it mention prerequisites or excluded scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already set readOnlyHint=true and destructiveHint=false, so the description's 'read-only' is redundant. It adds minor context by specifying 'SCPI query' and 'connected DPO2012B', but does not disclose response handling, error behavior, or connection prerequisites beyond the implied state.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence with no unnecessary words. It is appropriately front-loaded and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter) and the presence of an output schema and annotations, the description provides the core purpose but lacks details about the response format (e.g., string vs. binary) and the requirement that the device be connected. It is adequate but leaves some gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one required parameter 'command' with 0% description coverage. The description does not explain what the command should contain (e.g., a valid SCPI command string) or provide examples. It only implies that the parameter is a SCPI command, which is too minimal to compensate for the missing schema description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Send'), the resource ('SCPI query'), and the target ('DPO2012B'). It also includes 'read-only', which distinguishes it from sibling tools like dpo2012b_write_scpi and dpo2012b_command, and aligns with the tool's name and annotations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for read-only SCPI queries, but it does not explicitly mention when to use this tool versus alternatives such as dpo2012b_query_binary or dpo2012b_write_scpi. No exclusions or alternative tool names are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the tool as read-only and non-destructive. The description adds the optional 'probe identity' behavior, which is useful context, but does not disclose potential latency or failure modes when probing instruments. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence of ten words, front-loaded with the verb 'List'. No redundant content or unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present, return values are already documented. The description covers the core functionality and the optional parameter, but leaves the scope of 'VISA resources' slightly ambiguous. Overall adequate for a simple discovery tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has zero description coverage, and the lone parameter 'probe_identity' is not explained. The description's phrase 'optionally query each instrument identity' gives the parameter some meaning, but it does not clarify its default (true) or its impact on the output beyond implying a probe action.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists VISA resources and optionally queries instrument identity, distinguishing it from siblings like list_supported_devices and identify_instrument. The verb 'List' and resource 'VISA resources' provide specific, actionable scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance is given about when to use this tool versus alternatives. The description implies it is for resource discovery, but it does not mention exclusions or contrast with sibling tools such as list_supported_devices or connect functions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, which aligns with the 'Measure' description. The description adds the list of measurable quantities but does not disclose behavioral traits such as return format, units, or whether a measurement triggers a new acquisition. With annotations covering the safety profile, this is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence of 12 words that is front-loaded with the verb 'Measure.' It is concise and every word contributes to conveying the tool's scope. No redundant or filler content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the low complexity (one optional parameter), existing output schema, and read-only annotations, the description is mostly complete. It enumerates the supported measurement types, which is essential for an agent to decide usage. However, it omits expansion of abbreviations like 'DVM' and 'DRM' and does not clarify whether 'amp-hours' requires a specific setup or timeframe, leaving minor gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one optional parameter ('measurement') with a default of 'vcm' and no description (0% coverage). The description partially compensates by listing possible measurement types (voltage, current, DVM, combined VCM, amp-hours, DRM resistance), but it does not explicitly map these values to the 'measurement' parameter or explain the default. This adds some meaning but leaves ambiguity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Measure voltage, current, DVM, combined VCM, amp-hours, or DRM resistance.' It uses a specific verb ('Measure') and identifies the resource (m8811) and the scope (multiple measurement types). This distinguishes it from sibling tools like m8811_set_voltage or m8811_query_scpi.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no explicit guidance on when to use this tool versus alternatives. It does not mention m8811_query_scpi, m8811_get_settings, or any other tool that could also retrieve readings. The only implied usage is 'when you want to measure one of these quantities,' but no exclusions or alternative comparisons are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and destructiveHint, and the description does not contradict them. It adds a valuable behavioral disclosure that *IDN? serial data is redacted, which is not inferable from the schema or annotations. This exceeds the baseline but omits other potential behaviors like error handling.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence that front-loads the core purpose and appends a critical caveat about redaction. Extremely efficient—every word contributes meaning, with no redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple query tool with one parameter and an output schema, the description covers the essential purpose and a key output behavior. It omits connection prerequisites or exact response format, but the output schema likely covers return values, making this adequate overall.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has zero description for the 'command' parameter, so the description must compensate. It merely states the command should be a query from the manual, providing no syntax, formatting, or examples. This minimal guidance is insufficient for a parameter that carries the entire operation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as running SCPI query commands from the M88 manual, with a specific verb and resource. It distinguishes from write_scpi via the 'query' scope and the redaction note adds uniqueness, but 'any query' is slightly broad and doesn't explicitly differentiate from other query_scpi tools for different instruments.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The 'documented in the M88 manual' qualifier implies users should restrict to manual commands, but the description offers no explicit guidance on when to use this versus alternatives like m8811_measure or m8811_write_scpi. No exclusions or alternative references are provided, so usage context is only implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds behavioral context beyond the annotations by noting the output must be off and that DRM modes are 'guarded', hinting at a safety mechanism. Yet it does not explain what 'guarded' means, the role of confirm_drm, or the consequence of attempting with output on.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence of 13 words, front-loaded with the action and object, containing no filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The core function and a key constraint (output off) are present, but the description omits the meaning of 'guarded' DRM and the confirm_drm parameter. Given the safety-sensitive nature of the tool and sparse schema, this is a noticeable gap, though the output schema may cover return values.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It covers 'mode' by listing valid values, but provides no explanation for 'confirm_drm' (a boolean with default false), leaving a required aspect of the tool's behavior unclear.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Select') and identifies the resource ('mode'), enumerating the exact valid values (FIX, LIST, DRM/DRM0/DRM1/DRM2). This clearly distinguishes it from sibling tools like m8811_set_output or m8811_configure_list.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides a clear precondition ('while output is off'), which implies when this tool should be used. However, it does not explicitly contrast with alternatives or state when not to use it, leaving usage guidance largely implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds value by enumerating which settings are read, providing clarity on the tool's scope beyond what annotations alone convey. No contradictions exist between description and annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is front-loaded with the verb 'Read' and efficiently lists all setting categories. Every word earns its place with no filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the tool's scope well, and the output schema can elaborate on return values. However, it omits any explanation of the channel parameter, which is critical for correct invocation. Given the tool's simplicity and available annotations, it is acceptable but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% and the description does not mention the 'channel' parameter at all. The parameter name alone may hint at selecting an output channel, but without any description, default, or enums, the agent has to guess its meaning and valid values. The description completely fails to compensate for the lack of schema documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Read' and clearly identifies the resource (settings) along with the exact categories (output, waveform, modulation, sweep, burst, ARB, sync). This distinguishes it from sibling set tools like sdg1062x_set_waveform and other instruments' get_settings tools, making the purpose unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this tool is for retrieving current settings, but it does not explicitly state when to use it over alternatives like query_scpi or set tools. There are no when-to-use or when-not-to-use instructions, though the read-only nature and name suggest usage is for inspection or pre-change review.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, and the description aligns by stating 'non-destructive query'. It adds minimal extra context, such as that commands are documented by the Siglent guide, but doesn't describe response behavior or error handling. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence of 11 words, immediately front-loading the core action and scope. Every word contributes value, and it is appropriately sized for a simple tool with one parameter.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (one parameter), strong annotations, and presence of an output schema, the description covers the essential purpose and safety profile. It could mention that return values are provided via the output schema, but the current wording is sufficient for an agent to select and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With schema description coverage at 0%, the description must clarify the 'command' parameter. It indicates the command should be a query documented by the Siglent programming guide, which adds valuable context but doesn't explain the expected format (e.g., trailing '?') or provide examples. This is partial compensation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('send') and identifies the resource ('a non-destructive query documented by the Siglent programming guide'). It clearly conveys a read operation on the instrument but doesn't explicitly mention the return value or differentiate from sibling query tools beyond the 'non-destructive' qualifier.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use for reading/querying the instrument via SCPI commands and contrasts with write operations through the word 'query' and 'non-destructive'. However, it provides no explicit when-to-use vs alternatives, such as naming the sibling write_scpi tool or other query methods.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide no specific safety hints (all false), so the description carries some burden. It adds important context about the format (2..16384 points, normalized, 16-bit little-endian) but does not disclose side effects like overwriting an existing waveform of the same name or whether the upload persists in non-volatile memory. Since annotations exist but are unhelpful, a mid-range score is appropriate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no filler. It front-loads the core action and format, making it highly scannable. Every word provides value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a moderately complex tool with 7 parameters and no output schema details provided, the description covers the essential upload format but omits important context such as the meaning of 'normalized' (range) and how the uploaded waveform relates to the channel or later selection. Since there is an output schema (though not shown), return values are less critical, but the parameter semantics and device behavior remain under-specified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description only adds meaning for the 'points' parameter (normalized count range). It does not explain 'channel', 'name', or the numerical parameters like frequency, amplitude, offset, and phase, leaving the agent to infer their roles from the schema alone. This is insufficient for a 7-parameter tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: uploading a specific number of normalized points as a 16-bit little-endian user arbitrary waveform. It distinguishes itself from siblings like 'select_arbitrary_waveform' and 'set_waveform' by focusing on the upload action and format.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use this tool (when uploading a user-defined waveform) but does not explicitly contrast it with alternatives such as selecting an existing waveform or setting a standard waveform. There is no exclusionary guidance, so the usage context is implied rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, and the description simply repeats 'read-only' without adding new behavioral context. It does not disclose response format, timeout behavior, or whether the command should include a '?' suffix. The only added context is 'connected AFG-2125', which is not behavioral.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no wasted words. It efficiently conveys the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present and only one parameter, the description is mostly adequate. It specifies the target instrument and read-only nature. However, it lacks details on valid SCPI query formats or whether the tool automatically appends '?', but given the output schema and simple context, the completeness is acceptable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for the single 'command' parameter. It only says 'Send a read-only SCPI query' which implies the command is a SCPI query string, but it does not provide examples, mandatory '?' syntax, or error handling. This is minimal and does not fully compensate for the lack of schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (send), resource (read-only SCPI query), and scope (connected AFG-2125). It distinguishes from write operations and other instrument-specific query tools by naming the instrument and specifying read-only.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for reading instrument state via SCPI queries. It does not explicitly name alternatives like afg2125_write_scpi, but the 'read-only' qualifier provides clear context that this is not for writing. No exclusions are stated, but the read-only nature is a strong implicit guideline.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate this is a mutating operation (readOnlyHint=false), and the description adds the valid range of 0-100 percent. However, it does not disclose side effects, failure conditions, or how the setting interacts with the current waveform, so behavioral transparency is minimal but not absent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that directly states the action and the range with no filler or redundant information. It is appropriately sized for the simplicity of the tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter setter with an output schema, the description covers the essential action and range. However, it omits important context such as when this setting applies (e.g., only for ramp waveforms) and any prerequisites, making it slightly incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description compensates by specifying the valid numeric range (0 to 100 percent) for symmetry_percent. The parameter name is self-explanatory and the units are explicitly stated, giving the agent sufficient information to select an appropriate value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a clear action verb ('Set') with a specific resource ('ramp symmetry') and a valid range. It effectively distinguishes this tool from sibling tools like afg2125_set_square_duty and afg2125_set_offset by targeting ramp symmetry specifically.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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, nor are prerequisites mentioned (e.g., whether the ramp waveform must be selected first). The description simply states the action without any contextual cues.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide no helpful hints (all false), so the description carries the full burden. It only states what the tool does without disclosing side effects, idempotency behavior, prerequisites (e.g., whether a connection must exist), or impact on other connections. It doesn't say if calling disconnect on an already-closed connection is safe, which is a significant gap for a state-changing operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, 9 words, conveying the essential purpose without any wasted words. It is appropriately sized for a simple tool with no parameters, and the key qualifier 'only' is front-loaded, providing clear scope immediately.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple disconnect tool with no parameters and an output schema, the description covers the basic purpose but omits contextual details like when to call it (e.g., during cleanup), whether it's idempotent, or how it relates to the corresponding connect operation. Given the low complexity, this is adequate but not thorough; a 3 reflects the clear gap in usage context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the input schema is already complete (100% coverage). Per the baseline for zero-parameter tools, the description doesn't need to add parameter details. The description correctly stays silent on parameters, and no additional semantic guidance is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action (close) and the exact resource (Agilent/Keysight 33500B VISA connection). The word 'only' distinguishes it from other disconnect tools for different instruments, making its purpose unambiguous and differentiating it from siblings like `sdg1062x_disconnect` or `disconnect_instrument`.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when you need to close the 33500B connection, but it does not explicitly mention alternatives or when not to use it. It lacks guidance on choosing between this and the generic `disconnect_instrument` or sibling-specific disconnect tools. Usage is inferred from the name and 'only' qualifier rather than explicitly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate this is not read-only, not idempotent, and not destructive. The description adds no further behavioral context such as mutual exclusion between modes, preconditions, or side effects. It simply restates the toggle action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence with no filler. It efficiently conveys the tool's purpose and the list of supported modes.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple setter with an output schema, the description is mostly adequate, but it lacks exact accepted string values for the 'mode' parameter and does not explain the relationship to sibling configure/set tools. The low complexity prevents a lower score.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema only provides parameter names with no descriptions or enums, and schema coverage is 0%. The description compensates by listing the supported modes (AM/FM/PM/PWM/FSK/BPSK/SUM, sweep, burst), giving the agent key information about valid 'mode' values. However, exact string casing or syntax is not specified.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Enable or disable' and clearly identifies the resource: AM/FM/PM/PWM/FSK/BPSK/SUM, sweep, or burst. This distinguishes it from sibling configuration tools like configure_modulation or configure_sweep.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The enable/disable wording implies this tool is used to toggle modes on or off, but there is no explicit guidance about when to use it versus configure_* tools, nor mention of prerequisites like configuring a mode before enabling it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description implies a destructive or high-risk operation requiring confirmation, but annotations declare destructiveHint=false, creating a contradiction. The description adds no additional behavioral context beyond what the parameter already implies, and the contradiction is a serious issue.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that conveys both the action and the constraint without redundancy. It is front-loaded with the verb and resource.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter tool, the description provides the essential action and confirmation requirement. However, the contradiction with annotations undermines completeness, and it does not specify the exact effect (e.g., resets to zero) or any prerequisites. The output schema covers return values, so no further information is needed there.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The sole parameter confirm_clear is clearly referenced by the phrase 'explicit confirmation'. The description makes clear that the tool will not clear unless confirmation is given, providing value beyond the bare schema which has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the verb 'Clear' with a specific resource 'accumulated amp-hour counter', clearly stating the tool's function. It is distinct from sibling tools which mostly handle setting, measuring, or querying, and the confirmation condition adds clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states the tool should only be used 'after explicit confirmation', providing a clear safety guideline. It does not mention alternatives, but this tool is unique among siblings for clearing amp-hour counters, so the guideline is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses the readback behavior ('read back'), adding value beyond annotations which are all false. It does not detail side effects, error handling, or persistence, but for an instrument control tool the on-the-wire behavior is somewhat evident.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence that is front-loaded with the verb and resource, with no wasted words. The sentence is well-structured and immediately informative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no annotation support and an output schema present, the description covers the basic purpose but omits details like step indexing, units, or behavior on invalid input. It is adequate for a simple set/readback operation but not richly contextual.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It names 'voltage, current, or delay' which maps to voltage_v, current_a, and width_ms, giving semantic meaning. It does not explicitly map each parameter, nor discuss defaults, but the added context helps beyond bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Set and read back' and the resource 'voltage, current, or delay for one LIST step', identifying a specific action on a specific object. It distinguishes from siblings like m8811_set_voltage or m8811_set_current by scoping to a single LIST step.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied: the description conveys that it targets one LIST step, so the agent understands it is for modifying a specific step's parameters. However, no explicit when-to-use vs alternatives are given, nor any exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide no safety hints (all false), so the description adds value by labeling writes as 'safe documented' and pointing dangerous ones to typed tools. However, it does not explain the purpose of the confirm_unsafe parameter or behavior when unsafe commands are sent, leaving a transparency gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, tightly worded sentence that front-loads the purpose and includes the key alternative. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the critical safe/dangerous distinction and references typed alternatives, but it omits parameter semantics and the role of confirm_unsafe. Given the tool's simplicity and the availability of sibling tools, it is minimally adequate but not fully complete for safe invocation without additional inference.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description provides no explanation of the 'command' or 'confirm_unsafe' parameters. Agents are left without guidance on how to construct or validate the command string or when to set confirm_unsafe.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the action ('Run') and the target ('M88 write'), qualifying it as 'safe documented'. It distinguishes from siblings by noting dangerous writes belong to typed tools, but it is vague about the exact nature of the write beyond that distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly states when to use the tool (safe documented writes) and when not to (dangerous writes must use guarded typed tools), providing clear actionable guidance for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide no constraints (all false), so the description carries some burden. It adds the context that a 'declared VISA interface' is required, which is a prerequisite, but does not disclose side effects, idempotency, or cleanup behavior beyond the act of connecting.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that is front-loaded with the essential action and target. No wasted words, appropriate for a simple connect operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema, the description does not explain what the output represents or that connecting is a prerequisite for other sdg1062x operations. The brief text is insufficient for an agent to understand the tool's role in a larger workflow or handle errors.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. It hints that 'resource' is the VISA interface ('declared VISA interface'), adding some meaning. However, the 'timeout_ms' parameter is not explained at all, leaving a gap for agents.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Connect') and clearly identifies the target resource (Siglent SDG1032X/SDG1062X) and mechanism (VISA interface). This distinguishes it from sibling connect tools for other instruments.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description makes it clear this tool is for connecting to the Siglent SDG series, providing clear context. It does not explicitly name alternatives or exclusions, but the device-specific wording implies when it should be used.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With all annotations false, the description carries the burden of behavioral disclosure. It discloses the prerequisite that output must be disabled, but does not state what happens if output is enabled, nor any side effects or return behavior. This leaves a significant transparency gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, front-loaded with verb and object, no unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple, but the lack of annotation support and parameter detail makes the description minimally complete. It states purpose and a key precondition, but not enough for a new agent to invoke confidently without surrounding context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has no descriptions for the two required parameters. The description clarifies that 'polarity' accepts normal or inverted, but does not elaborate on valid string values or define the channel parameter (e.g., range). Partial compensation for low schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Set') and resource ('channel polarity'), and specifies the two possible states ('normal or inverted') plus condition ('while output is disabled'). It clearly distinguishes from sibling tools that set other output parameters.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear usage context ('while output is disabled') but does not explicitly mention when not to use or alternatives among siblings. No exclusions are given, but the context is sufficient to guide usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate this is not read-only and not destructive, aligning with the 'Enable and configure' action. The description adds the detail that the source can be internal or external, but does not disclose side effects like whether existing FSK settings are overridden or if output must be disabled. With annotations present, this is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is front-loaded with the main action and resource, followed by a key detail (source). No wasted words and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple configuration tool with defaults and an output schema present, the description is adequate but misses key context: it does not mention the rate and hop frequency parameters, nor does it clarify its relationship to set_fsk_enabled. An agent might need to infer those from the schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description only clarifies the 'source' parameter by mentioning internal/external. It does not explain 'rate_hz' or 'hop_frequency_hz', and schema description coverage is 0%. Since two of three parameters lack semantic context, the description only partially compensates for the schema's missing descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Enable and configure') and the specific resource ('FSK') with a scope qualifier ('with an internal or external source'). This distinguishes it from sibling tools like afg2125_configure_am or afg2125_set_fsk_enabled, as it covers both enabling and configuring FSK while specifying the source mode.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context by naming the source selection, which helps an agent know when to use this tool (when configuring FSK with a chosen source). However, it does not explicitly exclude alternatives like set_fsk_enabled or provide when-not-to-use guidance, so it misses the 'no exclusions' level.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide little positive info (all false). The description adds the behavioral detail of 'bounded PnP-filtered auto-detection when omitted', which is useful. But it does not disclose side effects, timeout behavior, or error handling, so the added value is moderate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. It states the primary action and a key behavioral detail efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple connect tool with an output schema, the description covers the essential behavior (connect, auto-detection optional). It omits details like timeout semantics and prerequisites, but the output schema and parameter defaults partially fill these gaps. It is adequate but not comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It partially explains the resource parameter (optional, auto-detection when omitted), but provides no explanation for timeout_ms. With only two parameters, this leaves half the parameters underspecified.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states 'Connect to an AFG-2125', giving a specific verb and resource. It distinguishes from sibling connect tools by naming the target instrument, and the auto-detection phrase adds further clarity. This is a clear, unambiguous purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when a connection to an AFG-2125 is needed, and clarifies that the resource parameter is optional via auto-detection. However, it does not explicitly mention when not to use this tool or name alternative connect tools for other instruments. The context is clear but lacks explicit exclusions or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds the precondition that MAIN output must be disabled, but it does not disclose what happens if the tool is called when MAIN output is enabled (e.g., error, ignored) or any side effects on FSK configuration. Annotations are sparse, so the description carries the responsibility for behavior, which it only partially fulfills.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that immediately conveys the action and the condition. No unnecessary words or repetition of schema details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter toggle with an output schema, the description provides the essential information: what it does and the key precondition. It does not explain edge cases or returns, but given the simplicity and presence of an output schema, this is acceptable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has a single boolean parameter 'enabled' with no description (0% coverage). The description's 'Enable or disable' strongly implies that true enables and false disables, which is adequate for a simple boolean toggle, but it does not explicitly bind the parameter values to actions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Enable or disable FSK') and the specific resource ('FSK'), with a clarifying condition ('while MAIN output is disabled'). It is distinct from sibling tools like 'set_am_enabled' and 'set_fm_enabled' by naming FSK explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'while MAIN output is disabled' provides a clear context for when the tool should be used, implying that it is only applicable when the main output is off. However, it does not explicitly state when not to use it or mention alternatives, though the condition is a strong implicit guideline.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds behavioral context beyond annotations, stating that the tool enforces current amplitude and a +/-5V output limit. However, it does not describe what happens on limit violation (clamp, error, etc.) or return behavior. Annotations provide no safety hints, so the description carries some burden but leaves gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that clearly names the action and the key constraint. Every word contributes to understanding, with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple setter with one parameter, the description is sufficient: it states the action and the critical constraint, and the output schema covers return values. It lacks explicit sibling differentiation, but that is a minor gap given the low complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With one parameter (offset_volts), the schema provides a clear title and type. The description adds no additional semantics beyond tying the parameter to DC offset. The 0% schema description coverage is compensated by the simple, self-explanatory nature of the parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Set DC offset') with a distinct resource and behavior. It distinguishes this from sibling set_* tools by focusing on offset while adding the constraint of preserving amplitude and output limit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context (set offset while enforcing constraints) but does not explicitly state when to use versus alternatives like set_amplitude or set_frequency. It provides no exclusion criteria or mention of siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that the operation does not select the waveform or enable output, which is useful behavioral context beyond the annotations (which are all false and unhelpful). However, it does not mention whether the upload overwrites existing data or any side effects, leaving some behavioral ambiguity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that conveys the core action and key constraints without wasting words. It is an excellent example of concise, high-density information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is relatively simple and an output schema exists, so return values need no description. However, the unexplained 'start' parameter and the lack of details about overwriting behavior or prerequisites make it incomplete for an agent to fully understand the tool's behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It explains the 'values' parameter range (-511..511) and count (2-4096), but the 'start' parameter is completely unexplained, leaving a significant gap in understanding required arguments.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool uploads arbitrary waveform points with specific constraints (2-4096 points, range -511..511). It also distinguishes itself from sibling tools like select_arbitrary_waveform by explicitly noting it does not select or enable output.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context: uploading waveform data without activating it, which differentiates it from select/configure operations. However, it does not explicitly name alternative tools or provide when-not-to-use guidance, so it falls short of a perfect score.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, indicating a safe read operation. The description adds context about channel selection but does not disclose any additional behavioral traits beyond what annotations provide, such as exact return values or error conditions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no redundant words. It communicates the essential purpose and scope efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only tool with a single parameter and an output schema, the description is nearly complete. It could define 'vertical settings' more explicitly (e.g., scale, offset) to reduce ambiguity, but given the annotations and output schema, the current level is adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema coverage, the description compensates by specifying that the 'channel' parameter can be 'CH1' or 'CH2'. This gives meaningful context beyond the raw schema, though it could further clarify that these are the only valid values and that the parameter is optional.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Read') and resource ('vertical settings') with a clear scope ('for CH1 or CH2'). It effectively distinguishes this tool from sibling measurement/acquire tools, which have different purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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, nor does it mention exclusions or prerequisites. It relies entirely on the tool name and generic read semantics.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds value by specifying which status categories are read (acquisition, trigger, horizontal, error), giving more detail than the tool name alone. However, it does not disclose any further behavioral traits such as return format or whether a connection is required, though the output schema may cover return format.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence of 8 words. It is front-loaded with the verb 'Read' and immediately specifies the resource and scope. Every word earns its place, with no redundancy or irrelevant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that the tool has no parameters, an output schema exists, and annotations cover read-only safety, the description is largely complete. It clearly states what statuses are retrieved. However, it lacks usage guidance or context about when to choose this over sibling tools, which is a minor gap for contextual completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline is 4. The description does not need to explain parameters, and the empty schema already indicates no arguments are required. The description's mention of status categories provides useful context about what the tool reports, but since there are no parameters, there is nothing more to add.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the action ('Read') and the resource ('status'), and adds specific scope by enumerating the status categories: acquisition, trigger, horizontal, and error. This distinguishes it from sibling tools like dpo2012b_get_channel_settings, which target different data. The verb+resource+scope structure matches the highest standard.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 such as dpo2012b_measure or dpo2012b_acquire_waveform. There are no explicit mentions of prerequisites, exclusions, or alternative tools. While the purpose is clear, the lack of any usage context means the agent must infer when this is the right choice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only indicate readOnlyHint=false and destructiveHint=false, but the description adds critical safety context about enabling output requiring confirmation. This goes beyond the structured annotations, though it does not elaborate on other behavioral aspects like error handling or return values.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no wasted words, but it sacrifices clarity for brevity. Terms like 'freely' and 'explicit confirmation' are ambiguous, yet the overall size is appropriate.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description lacks essential context for a tool with no schema coverage. It does not explain the channel parameter, the exact role of confirm_enable, or what happens if enable is requested without confirmation. The safety warning is useful but incomplete for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 3 parameters including required channel and enabled, plus confirm_enable, but the description does not explicitly name or explain any of them. 'After explicit cabling/load confirmation' hints at confirm_enable but does not map it clearly, and channel is completely undocumented. With 0% schema description coverage, this is inadequate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: disabling output freely or enabling it under a safety condition. This distinguishes it from sibling tools like sdg1062x_set_output_load and sdg1062x_set_output_polarity, which handle different output settings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to disable (freely) versus enable (after cabling/load confirmation), giving the agent a clear decision rule. It does not explicitly name alternatives, but this is not necessary for a basic setter tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, covering the main safety profile. The description adds value by specifying exactly which modes are read (AM, FM, FSK, sweep), but it does not disclose additional behavioral traits such as whether the tool queries live device state, returns cached values, or how it handles errors. This is adequate given the annotations but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, compact sentence that front-loads the verb and specifies the exact resource. Every word is meaningful, with no filler or repetition. It is highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool (0 parameters, an output schema exists, and the purpose is clearly stated), the description fully covers what the agent needs to know. The tool is a straightforward read-only getter, and the description is complete for this context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so there is nothing to explain. The baseline of 4 applies because no parameter documentation is needed; the description adds no parameter semantics but also cannot be faulted for omitting anything relevant.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Read') and the specific resource ('whether AM, FM, FSK, and sweep modes are enabled'). It distinguishes from sibling setter tools like afg2125_set_am_enabled and afg2125_configure_am by focusing on reading the enabled state of multiple modes at once. The scope is explicit and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidance is provided. The description does not mention when to use this tool versus alternatives like afg2125_get_settings or the individual mode setters, nor does it state any prerequisites or contexts. The tool's purpose implies it is for checking mode status, but that is not explicitly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, covering safety. The description adds that the query must be documented by the manual and is non-destructive, reinforcing but not significantly extending the annotation-provided behavior. No additional detail on error handling or response behavior is given.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence that immediately conveys the tool's purpose without redundancy or irrelevant information. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, no nested objects, annotations cover safety) and the presence of an output schema, the description is almost complete. However, it relies on the external 33500 Series manual for caller knowledge and omits practical details like whether the command should be a full SCPI query with a question mark, making it slightly less self-contained.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description provides no additional semantics for the single 'command' parameter. It does not explain expected format (e.g., whether to include a question mark), valid examples, or how the manual relates to acceptable commands. The tool name and schema title only restate 'command'.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool sends non-destructive SCPI queries documented by the 33500 Series manual. It uses a specific verb ('Send') and resource ('query'), and explicitly distinguishes from write operations by calling it non-destructive.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description conveys when to use this tool: for any non-destructive query documented by the manual. While it doesn't explicitly name alternatives like write_scpi for commands, the term 'query' and the non-destructive constraint imply the intended scope versus sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=true and destructiveHint=false, and the description adds that the operation uses the HARDCopy START command and returns Base64 image data. This gives useful behavioral context beyond the annotations, although it does not elaborate on return structure beyond the output schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler. It conveys the action, target, mechanism, and output format efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only screenshot tool with an output schema and annotations, the description covers the essential information: what is captured, how (HARDCopy START), and the output format. It lacks parameter detail, but given the simplicity of the tool, the overall context is reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one parameter, image_format, with no description, and the description does not explain valid format values or how they affect the output. Since schema description coverage is 0%, the description should compensate but only mentions 'Base64 image data' without relating it to image_format.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Capture' and resource 'DPO2012B screen', and adds the method 'HARDCopy START' and output format 'Base64 image data'. This clearly distinguishes it from sibling tools like dpo2012b_acquire_waveform and dpo2012b_measure.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The purpose statement implies this tool is for screen snapshots, distinct from waveform acquisition or measurement tools, but it provides no explicit when-to-use guidance or alternative tool names. An agent must infer usage from the tool name and sibling context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses a key behavioral trait beyond annotations: it 'enforces the offset/headroom limit', indicating the tool may adjust or reject values that exceed the limit. It also specifies 50-ohm output context. However, it doesn't detail the exact behavior on violation (clamp vs. error) or any side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that front-loads the primary action and packs key constraints (50-ohm, Vpp, headroom enforcement) without extraneous words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple setter with one parameter and an output schema available, the description covers essential semantics: amplitude unit and the headroom limitation. It could mention whether the setting applies to the currently selected channel, but given its simplicity, this is adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter amplitude_vpp is given crucial context by the description: it is in Vpp and for a 50-ohm output. However, with 0% schema coverage, the description does not fully compensate—no range, minimum/maximum, or detailed constraint behavior is provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific action (set amplitude), the target resource (AFG2125 output), and the value semantics (50-ohm output amplitude in Vpp). It distinguishes itself from sibling tools like afg2125_set_frequency or afg2125_set_offset by including the headroom constraint.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the use case (setting output amplitude) and hints that the tool automatically enforces the offset/headroom limit, but it does not explicitly state when to use this tool over alternatives or when not to use it. No direct comparison to similar setter tools is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses an important behavioral trait beyond the annotations: enabling the output is gated by a confirmation requirement, while disabling is unconditional. This adds safety context that the annotations (readOnlyHint=false, destructiveHint=false) do not convey. It does not contradict the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that front-loads the core action and adds a necessary caveat. Every clause adds value, with no redundant or filler content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (2 parameters) and the presence of an output schema, the description covers the main usage policy. However, it leaves ambiguity about parameter semantics and does not explain what happens if confirm_enable is false when enabling, making it only minimally adequate for an agent to invoke correctly without further insight.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description was expected to compensate, but it does not explicitly explain the roles of the 'enabled' and 'confirm_enable' parameters. The phrase 'enable it only after explicit load and cabling confirmation' hints at confirm_enable's purpose but does not directly map to the parameters or clarify their interplay.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: to disable or enable the output, with a specific condition for enabling. It distinguishes this tool from sibling set_output tools by adding the safety requirement of load and cabling confirmation, which is unique to this instrument.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context on when to use the tool: disabling can be done freely, while enabling should only occur after explicit load and cabling confirmation. This implies a when-not-to-use condition, though it does not explicitly name alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is known. The description adds the list of settings read but does not disclose any additional behavioral aspects such as returning a snapshot, requiring an active connection, or potential performance implications. It meets the baseline with annotations but adds limited extra context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, directly starts with the verb 'Read', and lists exactly the relevant state groups. No filler or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema available and no parameters, the description sufficiently outlines the tool's coverage. It enumerates all major settings categories, though it doesn't mention prerequisites or output structure details, which the schema covers. Adequate for a simple getter.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters, so the baseline is 4. The description correctly indicates the scope of the read operation without needing to document argument semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Read' and enumerates the resource (channel, output, sync, modulation, sweep, and burst state), clearly identifying it as a read-only settings retrieval tool. It distinguishes well from sibling setters like agilent33500b_set_output and agilent33500b_configure_modulation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use or alternatives are provided. The read-only nature is implied by 'Read' and the tool name, but the description does not mention when to prefer this over other get tools or caution against using it in write workflows.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only and non-destructive behavior. The description adds that it operates on the 'connected' instrument and returns two pieces of information (identity and VISA resource), but it does not disclose behavior if no instrument is connected or any error handling. This is minimal extra context beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no filler words. It efficiently communicates the tool's purpose without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the low complexity (zero parameters) and the existence of an output schema, the description is sufficient: it states what is returned and that it pertains to the connected instrument. It could mention prerequisites more explicitly, but the word 'connected' provides adequate context for a simple identify operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters, so there is nothing for the description to explain about inputs. Baseline is 4 for zero params; the description correctly makes no param claims.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Return') and the specific resource ('connected 33500B identity and VISA resource'). It distinguishes from sibling tools by naming the exact instrument model, making 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.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The usage is implied: one must have a connected 33500B, but the description does not explicitly mention when to use this over alternatives like the generic identify_instrument or per-other-device identify tools. No exclusions or alternative tool names are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds behavioral context beyond annotations by explaining the query flag's role and noting that writes are protected by the same unsafe-command policy as agilentdsox2012a_write_scpi. It also notes support for semicolon-separated queries. This is useful despite the annotations already indicating non-read-only behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise: two sentences, front-loaded with the core purpose, followed by key usage details. Every sentence adds value without repetition or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a generic SCPI command tool, the description covers the main aspects: command execution, query mode, and safety policy. It does not fully elaborate on the confirm_unsafe parameter or the exact return format, but the presence of an output schema and the reference to an existing policy make the description reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description must compensate for parameter semantics. It explains the 'query' parameter ('Use query=true for read-only queries') and implies the meaning of 'confirm_unsafe' by referencing the unsafe-command policy, but it does not explicitly describe 'confirm_unsafe' or the exact syntax/format of the 'command' parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Execute any SCPI command documented for the 2000 X-Series DSO-X 2012A.' It uses a specific verb and resource, and distinguishes itself from sibling query/write tools by describing both read and write capabilities, noting that writes follow the same unsafe-command policy as agilentdsox2012a_write_scpi.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives some usage context: 'Use query=true for read-only queries' and mentions an unsafe-command policy for writes. However, it does not explicitly say when to choose this tool over the more specific query_scpi or write_scpi siblings, leaving the alternative selection to be inferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is known. The description adds that the read concerns 'vertical settings', which is useful domain context, but it does not disclose additional behaviors such as error handling for invalid channels.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. It is concise and immediately conveys the essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is a simple getter with one optional parameter and an output schema present. The description is brief but covers the core operation. It does not list the returned vertical settings, but the output schema likely handles that, so this is acceptable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has one parameter 'channel' with no description (0% coverage). The description compensates by specifying 'CH1 or CH2' as the valid values, providing meaning beyond the schema. However, it does not specify the exact string format or default behavior.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Read'), the resource ('vertical settings'), and the scope ('CH1 or CH2'). It is specific and distinguishable from sibling tools like get_status or get_capabilities.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool (when you need vertical channel settings), but it does not explicitly mention alternatives or when not to use it. The context is clear but lacks explicit exclusions or comparisons.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the agent knows this is a safe read operation. The description adds the Base64 return format, which is useful, but it doesn't mention potential pitfalls like command validity or connection requirements. The added value beyond annotations 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.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, 13 words, with no filler. It front-loads the action and resource, then states the output format. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple: one parameter, output schema exists, and annotations cover safety. The description explains the core purpose and return format. It lacks caveats like 'command must be valid SCPI' but those are common across sibling tools and not strictly necessary for this simple operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one parameter 'command' with no description, and the description gives minimal guidance by indicating it should be a 'documented binary-block query'. While this hints at the expected input, it doesn't provide examples or syntax details, leaving the parameter semantics under-specified.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: running a binary-block query and returning bytes as Base64. It specifies the resource (binary-block query) and the output format, distinguishing it from query_scpi (which likely returns text) and write_binary (which writes data).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'documented binary-block query' sets clear context for when to use this tool: when you need to execute a query that returns binary data and you know a documented command. However, it does not explicitly mention alternatives or when not to use it, such as preferring query_scpi for text responses.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, and the description's 'Check' is consistent with a safe, non-mutating operation. The description adds context about what is checked (USB enumeration, VISA runtime, PyVISA readiness), extending beyond annotations. However, it does not disclose whether the tool requires an active instrument connection, the format of results, or potential side effects like system-level queries, which would be helpful.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence: 'Check Windows USB enumeration, VISA runtime, and PyVISA readiness.' It is front-loaded with the verb and immediately lists the specific items checked. No unnecessary words or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter diagnostic tool with an output schema, the description is nearly complete. It specifies the exact areas checked. Minor gaps: it does not explicitly tie the diagnostic to the DPO2012B instrument (relies on the tool name), and it does not indicate whether this is a host-side check or requires the instrument to be connected, which would be useful context for a user.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema description coverage is 100% (empty object). Per rubric baseline, 0 params earns a 4. The description adds nothing about parameters because none exist, and none are needed. It does not need to compensate for schema gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Check' and clearly identifies the resources: 'Windows USB enumeration, VISA runtime, and PyVISA readiness.' It distinguishes this tool from siblings like dpo2012b_connect or dpo2012b_identify by focusing on environment/dependency validation rather than device interaction. The tool name also scopes it to the DPO2012B oscilloscope, 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.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for diagnosing setup issues, but it does not explicitly state when to use this tool versus alternatives. It does not mention exclusions or alternatives such as 'use this before connecting' or 'use dpo2012b_connect after this passes.' No when/when-not guidance is provided beyond the general diagnostic intent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With all annotations false, the description carries the full burden. It states the tool closes a VISA connection but provides no details on idempotency, error handling, resource cleanup, or what happens if no connection is open. This is minimal 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.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence with no wasted words. It conveys the essential action and scope efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is very simple (0 parameters, output schema present), and the description sufficiently explains its core purpose. A minor gap is the lack of guidance on edge cases like idempotency or connection state, but the simplicity and output schema reduce the need for extensive detail.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool accepts zero parameters, and the schema coverage is 100%, so the baseline is 4. The description adds no parameter-specific meaning, but none is needed for a parameterless tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Close') with a clear resource ('DPO2012B VISA connection') and the word 'only' distinguishes it from siblings that disconnect other instruments or the generic disconnect_instrument tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies this tool is for closing the DPO2012B VISA connection specifically, and 'only' hints at excluding other connections. However, it does not explicitly state when to choose this over the generic disconnect_instrument or other instrument-specific disconnect tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide no behavioral hints (readOnlyHint, destructiveHint, idempotentHint are all false), so the description carries the burden. It discloses the action and scope, but does not describe what happens if already disconnected, error behavior, or effects on other connections.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. It states the action and the unique scope efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter disconnect tool with an output schema present, the description is minimally sufficient. It could mention reconnect requirements or distinguish itself from generic disconnect tools, but the tool's simplicity limits the gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the description need not explain parameter semantics. A baseline of 4 is appropriate because there is nothing to clarify.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Close') and clearly identifies the resource ('the M8811 serial connection'). The word 'only' explicitly differentiates it from sibling disconnect tools for other instruments.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this tool is used to disconnect the M8811, but it does not explicitly state when to choose it over generic disconnect_instrument or sibling device-specific disconnect tools. No alternative tools or exclusions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are all false and provide little behavioral information. The description adds crucial safety context: enabling the output is risky and requires explicit confirmation/read-back, while disabling is unrestricted. This is valuable beyond the schema and annotations, though it does not detail the read-back mechanism.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
One sentence, immediately front-loads the critical constraint ('Disable freely') and packs the enabling condition into a single clause. Every word is meaningful; no filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With only two parameters, an output schema, and all-false annotations, the description covers the core safety-critical rule. It does not explain the read-back step or parameter details further, but those are partially covered by the schema and the simplicity of the tool. Overall adequate for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It implicitly maps 'enable' to the enabled parameter and 'explicit load/cabling confirmation' to confirm_enable, but it never names the parameters or explains confirm_enable's default behavior. Partial compensation for the missing parameter descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description says 'Disable freely, or enable only...' which clearly conveys that this tool toggles the output state (enabled/disabled) for the m8811 device. It is specific enough to distinguish from sibling tools by device prefix, though it could more explicitly state 'set output on/off'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides direct usage guidance: disabling is safe ('freely') and enabling requires explicit load/cabling confirmation and read-back. This tells the agent when it is appropriate to use enabled=true versus false, and it warns against unsafely enabling the output.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses a key behavioral trait: it verifies that both outputs are disabled before copying, which is a safety check. It also implies a write operation, matching annotations (readOnlyHint=false). Beyond that, it does not describe failure modes or effects on the target channel, but the annotation hints are non-committal, so the description adds useful context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with the verb front-loaded and no redundant words. It conveys the essential action and condition in minimal space.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has a simple two-parameter schema and an output schema exists, but the description leaves ambiguity about what specific parameters are copied, whether the target channel is overwritten, and what happens if outputs are not disabled. It gives the precondition but not the full behavioral contract, making it somewhat incomplete for a mutation operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, and the description does not elaborate on the meaning of 'source_channel' or 'target_channel'. While these names are self-explanatory, the description does not specify allowed values (e.g., 1 or 2) or clarify that 'channel parameters' refers to the copied object, not the parameter fields.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Copy' with a clear resource 'channel parameters' and adds a precondition. It distinguishes itself from sibling tools by naming a unique copy operation not present in any other tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'after verifying that both outputs are disabled' provides a clear context for when the tool is safe to use. However, it does not explicitly mention when not to use it or offer alternative tools, but no alternative copy tool exists among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With all annotation hints set to false, the description carries the full burden of behavioral disclosure. It adds useful context by explaining that null means high impedance and that the setting is applied only when output is disabled. However, it does not mention potential errors, side effects, or whether the setting is persistent, leaving some behavioral aspects undisclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that immediately states the action, the parameter's special null value, and the required condition. Every word contributes meaning, with no redundant or filler content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter setter, the description provides essential context: the meaning of null, the precondition of output disabled, and the resource being configured. An output schema exists to describe return values, so no further detail is needed there. It could mention what happens if output is enabled, but for a low-complexity tool this is reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, so the description must compensate. It explicitly clarifies that null for load_ohms means high impedance, adding meaning beyond the schema's type union. However, it does not explain the channel parameter (e.g., 1-based indexing), leaving a gap for one of the two parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the action (Set), the resource (expected output load on the SDG1062X), and specifies a crucial condition ('while output is disabled'). It is distinct from sibling tools like sdg1062x_set_output, which controls the output state, and does not conflate with other setters.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear usage context by stating the operation should be performed while the output is disabled, which is a key timing constraint. It does not explicitly mention exclusions or alternative tools, but this condition effectively guides when to use the tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds the prerequisite that the device must be 'connected', which is a useful behavioral context beyond the readOnlyHint annotation. It does not describe error behavior, return format, or VISA resource details, but the output schema covers return structure, and the operation is a simple read with annotations already declaring safety. This adds some but not rich 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.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that directly states the tool's purpose and condition. It is front-loaded with the verb 'Return' and contains no unnecessary words or details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With zero parameters, an output schema, and read-only annotations, the description provides sufficient context for a simple identity retrieval tool. It specifies the device type and precondition (connection), making it complete for this low-complexity operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the input schema is trivially complete (100% coverage). The description clarifies the target device ('connected AFG-2125'), which is the only semantic needed. A score of 4 aligns with the baseline for no-parameter tools.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (Return), the resource (the connected AFG-2125 identity and VISA resource), and is specific to the AFG-2125 instrument. This distinguishes it from sibling identify tools such as m8811_identify or identify_instrument.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'connected AFG-2125' implies the tool should be used after establishing a connection, and the AFG-2125 prefix differentiates it from generic identify_instrument. However, it does not explicitly state when to prefer this tool over alternatives or mention exclusions, so usage guidance remains implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are all false, so the description carries the behavioral disclosure burden. It reveals that output should be disabled before setting the load, which is a valuable behavioral trait. However, it doesn't state what happens if the output is already enabled, whether the setting is persistent, or any side effects. This is partial transparency, not comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence with no fluff. Every word contributes to meaning: the verb, the resource, the unit, the null case, and the precondition. This is exemplary conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter setter with an output schema, the description covers the essential information: what is set, the parameter meaning, and the precondition. It doesn't mention valid ranges or error behavior, but these are less critical given the simple nature of the tool and the presence of an output schema. The description is mostly complete, though it could add a note about typical values or errors.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must explain the parameter. It fully does: 'in ohms' gives the unit, and 'or null for high impedance' clarifies the null case. This is exactly the semantic meaning an agent needs, especially since the schema only says 'number or null' with no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Set') and resource ('expected load') with clear scope: setting output load in ohms or high impedance via null. It clearly distinguishes from sibling tools like agilent33500b_set_output (which toggles output) and the SDG equivalent by including the device-specific naming and the 'with output disabled' context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'with output disabled' provides a precondition/context for when this tool should be used, but there is no explicit guidance on when to use this instead of alternatives (e.g., agilent33500b_set_output) or any exclusions. Usage context is implied rather than fully articulated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish readOnlyHint=true and destructiveHint=false. The description confirms the read nature and adds specificity about which device attributes are read (model, firmware, options, channel count, interfaces), which is useful context beyond the annotations. No contradictions or unexpected side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence of 12 words, front-loaded with the verb 'Read', and lists the exact items read. Every word adds value, with no filler or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple, parameterless interface, presence of an output schema, and clear annotations, the description fully specifies the tool's purpose. The output schema handles return-value details, so the description is sufficient for an agent to select and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool accepts zero parameters, and the schema is trivially covered (100%). The description correctly notes that no arguments are required, and the baseline of 4 applies for a parameterless tool. No additional parameter meaning is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Description uses the specific verb 'Read' and enumerates exact capability items: model, firmware, options, channel count, and declared interfaces. This clearly distinguishes it from sibling tools like agilentdsox2012a_get_settings and identify_instrument.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to invoke this tool versus alternatives such as get_settings or other instruments' get_capabilities. The description is purely descriptive, leaving the agent to infer usage from the name and sibling context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and destructiveHint, so the description's 'Read' is consistent and adds the specific status categories (acquisition, trigger, timebase, system-error). However, it does not disclose return format, potential side effects, or other behavioral nuances beyond what annotations already cover.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that is front-loaded and free of redundant information. Every word contributes to defining the tool's purpose without unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a no-parameter, read-only status tool, the description is fully sufficient. It enumerates the status categories, and the output schema (present in context) presumably details the return structure. The tool is simple enough that no additional context is needed beyond what is provided.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline is 4. The description correctly adds no parameter information, and the empty schema is fully accurate for a parameterless status read tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Read' and the specific resources: acquisition, trigger, timebase, and system-error status. This distinguishes it from sibling tools like get_channel_settings or measure, and the tool name aligns with the described function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for retrieving status information but does not explicitly state when to use this tool versus alternatives like query_scpi or get_channel_settings. No exclusions or alternative recommendations are provided, so guidance is only implicit via the tool's purpose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is known. The description adds the 'connected' qualifier, indicating it operates on the active connection, but provides no further behavioral details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that fully captures the tool's purpose without waste or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple zero-parameter identify tool with an output schema and strong annotations, the description is complete. It clearly states what is returned and requires no additional context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the description needn't explain any. Schema coverage is trivially 100%, meeting the baseline for parameter clarity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns the connected DSO-X 2012A identity, using a specific verb and resource. It distinguishes itself from sibling tools like get_status or connect by focusing on identity retrieval.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied by the tool name and description—it identifies the connected instrument—but there is no explicit when-to-use or alternative guidance. The context is clear but not elaborated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false. Description adds that it returns identity and VISA resource, which is useful but limited. Does not disclose behavior when no instrument is connected.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
One sentence, no redundancy, front-loaded with the verb and resource.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no parameters, output schema present, and read-only annotations, the description is sufficient to understand the tool's purpose and return value.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has zero parameters, so baseline is 4. Description adds no parameter information because there are none to describe.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool returns the DPO2012B's identity and VISA resource, using a specific verb and resource. It differentiates from generic identify_instrument and other instrument-specific identify tools by naming the exact instrument.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this vs alternatives like identify_instrument or other per-instrument identify tools. The mention of 'connected' implies it should be used after connection, but this is not spelled out.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, covering the safety profile. The description adds what is read (output state, mode, etc.), which is useful context beyond annotations. However, it does not disclose any additional behavioral traits such as return format or latency, which is acceptable given the existing annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that lists the contents clearly with no wasted words. It is concise and easily scannable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present and no parameters, the description provides sufficient context for a read-only settings retrieval tool. It covers the key categories of settings and is complete for the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does 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 description does not need to add parameter details. The baseline for 0 parameters is 4, and the description appropriately focuses on the resource being read.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Read' and clearly specifies the resource: output state, mode, setpoints, protection, and rated model limits. This distinguishes it from sibling tools like m8811_measure (which likely reads measured values) and other get_settings tools for different devices.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for reading configuration settings, but provides no explicit guidance on when to use this tool versus alternatives. There is no mention of exclusions or contrast with measurement tools like m8811_measure, so it falls short of clear contextual guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses a significant behavioral trait – the instrument has no read-back for this command, so the result cannot be verified. This goes beyond the annotations, which are all false and provide no safety clues. The explicit confirmation warning also adds cautionary context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
One efficient sentence with a semicolon, front-loading the core action and appending a necessary caution. There is zero redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present, return values are covered. However, the description plus schema still leave the 'area' parameter ambiguous. The tool is relatively simple but cryptic, lacking some instrumental context that would make it fully self-contained.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description only hints at the confirm_recall parameter via 'explicit confirmation'. The 'area' parameter is completely unexplained, leaving a gap. The description partially compensates but not sufficiently for low coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
States 'Load stored LIST data' – a specific verb and resource. It distinguishes from sibling tools like m8811_configure_list or m8811_set_list_step by focusing on recall/loading, and the caution about explicit confirmation adds unique scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides a clear condition ('only after explicit confirmation') and a reason ('manual has no read-back'), giving the agent when-to-use context. However, it does not explicitly name alternative tools or state when not to use it, so it's clear context without exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds minimal context beyond the annotations, clarifying that only the Siglent connection is closed. However, it does not disclose potential side effects, error behavior, or whether the operation is idempotent. With all annotation hints false, the description carries the burden but only partially fulfills it.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that directly states the action and scope. It is front-loaded with the key information and contains no unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with no parameters and an existing output schema, the description is sufficiently complete. It clearly conveys the tool's only action without needing additional context about return values or complex behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does 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. According to the rubric, a baseline of 4 is appropriate for tools with no parameters, and the description does not need to compensate for missing parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the action ('Close') and the specific resource ('the Siglent SDG connection'), making its purpose unambiguous. The word 'only' distinguishes it from more general disconnect tools like disconnect_instrument or other device-specific disconnects.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies that this tool targets only the Siglent SDG connection, but it does not explicitly state when to use this tool versus alternatives like disconnect_instrument or other device-specific disconnects. No exclusions or alternative references are given, so usage guidance is merely implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate a mutating operation (readOnlyHint=false). The description adds the non-obvious constraint that MAIN output must be disabled, which is a meaningful behavioral disclosure. However, it does not mention failure modes, persistence, or interaction with other modulation settings, so the added detail is modest.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one sentence, starts with the action, and includes the most important condition. There is no wasted wording or unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-boolean toggle, the description covers the core action and a critical prerequisite. It does not discuss edge cases like behavior when MAIN output is enabled or whether AM must be configured first, but the tool's simplicity limits the impact of those omissions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description carries the burden. The phrase 'Enable or disable AM' directly maps the boolean 'enabled' parameter to true/false states, and the added 'MAIN output disabled' condition clarifies when the parameter takes effect. This compensates for the schema's minimal description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb+resource pair ('Enable or disable AM') and adds a key condition ('while MAIN output is disabled'). This clearly distinguishes it from sibling tools like afg2125_set_fm_enabled and afg2125_configure_am.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context by specifying that this operation applies while MAIN output is disabled. It does not explicitly name alternatives or state when not to use it, but the precondition is a useful usage hint.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that frequency is constrained by an AFG-2125 limit and that the function parameter can be selected or supplied. It does not describe error handling or clamping behavior if the limit is exceeded, but the limit note adds some value beyond the annotations, which are all false.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that front-loads the action and includes only essential scoping details, with no unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple setter with an output schema available, the description adequately covers the purpose, the function parameter semantics, and the device limit. It does not explain what happens if the requested frequency is out of range, but that is a minor gap for this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The phrase 'selected or supplied function' clarifies that the optional 'function' parameter defaults to the currently selected function when not supplied, adding meaning beyond the schema's bare nullable default. The required frequency_hz is self-explanatory from its name.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (Set), the resource (frequency), and the scope (within AFG-2125 limit, for the selected or supplied function). It distinguishes this from sibling tools that set other parameters like amplitude, offset, or duty cycle.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context that this tool sets frequency, which distinguishes it from alternatives. However, it does not explicitly mention when not to use it or name alternative tools for other waveform parameters.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide no safety profile (readOnlyHint false, destructiveHint false, etc.), so the description carries full responsibility. It adds the precondition about MAIN output being disabled, but does not explain what happens if that precondition is violated, nor any side effects or persistence behavior. This is a minimal but acceptable level of transparency for a simple setter.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no redundant words. It leads with the verb phrase and gives the essential condition, making it highly scannable and concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-boolean-parameter tool, the description covers the purpose, parameter semantics, and the key precondition. The presence of an output schema reduces the need to document return values. It is complete enough for an agent to select and invoke the tool correctly, though it doesn't address error cases when MAIN output is enabled.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides 0% description coverage for the single 'enabled' parameter. The description explicitly maps true to 'enable' and false to 'disable' via 'Enable or disable frequency sweep', thus fully compensating for the schema gap and giving the parameter clear meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('Enable or disable frequency sweep') and includes a critical condition ('while MAIN output is disabled'), which not only clarifies the tool's function but differentiates it from sweep configuration tools like afg2125_configure_sweep and other set_enabled toggles.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'while MAIN output is disabled' provides a clear precondition for using this tool, implying it should only be called when the main output is off. However, it doesn't explicitly mention alternatives or exclusions, so it loses a point for not naming when to use configure_sweep instead.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate the operation is not read-only, and the description adds important behavioral nuance: enabling carries a safety prerequisite, while disabling is 'free.' This goes beyond the structured annotation fields and helps the agent understand the risk profile.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence with no wasted words. It efficiently communicates the core action and the key safety qualifier.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter tool with an output schema, the description covers purpose, usage context, and safety. The only minor gap is the lack of explicit parameter mapping for 'confirm_enable', but overall it is sufficient for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description adds meaning for the 'enabled' parameter (disable vs. enable semantics) and hints at the 'confirm_enable' parameter through 'explicit cabling and load confirmation.' However, it does not explicitly map that phrase to the confirm_enable parameter, leaving some ambiguity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Disable'/'enable') and resource ('output' implicitly for the Agilent 33500B), with a clear scope and a distinctive safety condition. It distinguishes from sibling set_output tools by highlighting the load-confirmation requirement for enabling.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It clearly states when to use the tool: disabling is always acceptable, while enabling requires explicit cabling and load confirmation. It does not name alternatives but provides strong contextual guidance for this specific device and operation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate a write operation (readOnly=false) and non-idempotent/non-destructive behavior; the description adds valuable context: the output must be off, and the manual documents no state query, so there is no way to read back the setting. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence that starts with the verb, states the resource, includes the essential precondition, and adds a caveat. Every word contributes; no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-boolean setter, the description covers the core action, the required output-off state, and the absence of a read-back query. It omits behavior if the output is on, but the explicit precondition makes this a minor gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter, 'enabled', has a self-explanatory name and the description clarifies that it controls remote sense, but the description does not explicitly state the true/false mapping or any default value. With 0% schema description coverage, this is minimally adequate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Set') and resource ('remote sense') with a clear precondition ('while output is off'). It distinguishes this tool from sibling setters like m8811_set_panel_control and m8811_set_output by naming the exact setting being changed.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly states when the tool is valid ('while output is off') and notes the lack of a state-query command, which implies verification limits. However, it does not name alternative tools or explicitly state when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is established. The description adds value by disclosing exactly what is checked: USB enumeration, VISA resources, and PyVISA readiness. This is meaningful behavioral context beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, compact sentence that front-loads the action ('Check') and lists the specific areas checked. Every word earns its place; there is no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter diagnostic tool with an output schema and clear annotations, the description adequately covers the tool's scope. It mentions three distinct readiness aspects, which is complete enough for an agent to select and invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline is 4. The description compensates by clarifying what the diagnostic covers, which is sufficient given there is nothing to parameterize.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Check' and identifies concrete resources: 'Siglent SDG USB enumeration, VISA resources, and PyVISA readiness.' This clearly distinguishes it from sibling diagnose_setup tools for other instruments and from connection/identification tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'readiness' implies this tool is used to verify setup before operating the SDG1062x, but it does not explicitly state when to use it versus alternatives like connect or identify. No exclusions or alternative selection guidance is provided, making the usage context only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, and the description's 'Read' verb aligns with this. It adds useful context by enumerating the specific capability categories (channels, bandwidth, ARB, interface), which goes beyond the annotations. No contradiction found.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that front-loads the verb and resource. Every word contributes meaning with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (zero parameters), the presence of an output schema, and strong annotations, the description is sufficient. It identifies the key output aspects and differentiates from get_settings. A slightly higher score would require explicit guidance on when to use this vs. sibling tools, which is handled under usage guidelines.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the schema provides complete coverage (100%). The description compensates nothing needed for parameters, but its enumeration of the returned capability domains adds semantic meaning to the tool's purpose. Baseline of 4 is appropriate for a parameterless tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Read') and resource ('model-specific channels, bandwidth, ARB, and interface capabilities'), clearly distinguishing it from sibling tools like sdg1062x_get_settings and agilent33500b_get_capabilities. It immediately conveys the tool's function and scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is used to retrieve capabilities but provides no explicit guidance on when to choose it over alternatives such as get_settings or get_capabilities for other models. There is no mention of prerequisites or exclusions, so usage context is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is known. The description adds value by enumerating the specific layers checked (USB CDC driver, COM port, VISA ASRL, PyVISA readiness), enriching the behavioral contract beyond what annotations provide. No contradiction exists.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler. It conveys the complete scope in under 15 words, every word earning its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a parameterless diagnostic tool with output schema and read-only annotations, the description fully covers the tool's scope. It names every component checked (driver, COM port, VISA ASRL, PyVISA) and leaves no material gap in understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the schema is trivially 100% covered. The description adds semantic context by listing what is inspected, which is more meaningful than the empty schema alone. Baseline 4 for no parameters is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Check' and names the exact resource: 'AFG-2125 USB CDC driver, COM port, VISA ASRL, and PyVISA readiness.' This clearly distinguishes it from sibling diagnose_setup tools for other instruments and from general VISA listing tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The intended usage is implied as a pre-flight or troubleshooting diagnostic for AFG-2125 setup, but the description provides no explicit when-to-use/when-not-to-use guidance or alternatives. It does not clarify how this relates to afg2125_connect or list_visa_instruments.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint=true and destructiveHint=false. The description adds that the tool will warn about a specific bug, which is useful behavioral context beyond the safety flags. However, it does not detail the warning's trigger conditions or content.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that front-loads the core action ('Read AFG settings') and then adds the warning. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no parameters and has an output schema, so the description is sufficient by stating the basic function and the additional warning. It provides enough context for an agent to select and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters, so the schema is trivially complete. The description adds no parameter information, but none is needed; baseline is 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool reads AFG settings (a specific verb+resource) and adds a unique warning about the V1.11 cold-start SYNC duty-cycle bug, distinguishing it from other get_settings tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for reading settings and receiving a bug warning, but it does not explicitly state when to use this tool versus alternatives like afg2125_get_mode_settings, nor does it mention any exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate a read-only, non-destructive operation. The description adds specific behavioral context by enumerating exactly what is checked (USB enumeration, VISA resources, PyVISA readiness), which is useful beyond the structured annotations. It does not contradict annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that directly conveys the tool's purpose without redundancy. Every word contributes meaningful information, and the structure is immediately scannable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter diagnostic tool with existing annotations and an output schema, the description is sufficiently complete. It clearly scopes the diagnostic to the 33500B instrument and names the key domains checked, which is enough for an agent to select and invoke it appropriately.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so there are no parameter semantics to explain. The schema coverage is trivially 100%, and the description's focus on diagnostic checks is sufficient given the absence of inputs.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Check') and identifies a clear resource (33500B), enumerating three concrete aspects: USB enumeration, VISA resources, and PyVISA readiness. It is easily distinguished from sibling tools like connect, identify, or list_visa_instruments.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The intended use is implied by the tool name 'diagnose_setup' and the description, but no explicit guidance is provided about when to use this tool versus alternatives such as connect, identify, or list_visa_instruments. There are no exclusions or alternate tool recommendations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds valuable scope context ('all active... discovery VISA sessions') beyond what annotations provide. Annotations do not contradict the description; closing sessions is correctly marked as non-destructive. However, it doesn't mention potential side effects like invalidated handles, which would have made it a 5.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no wasted words. It clearly states the action and the exact scope without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters and an output schema exists, the description is complete. It specifies exactly what resources are affected (all active instrument and discovery VISA sessions), which is sufficient for an agent to select and invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the description doesn't need to explain parameter details. Per the rubric, the baseline for 0 parameters is 4, and the description doesn't miss anything required.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Close' and clearly identifies the resource: 'all active instrument and discovery VISA sessions.' This distinguishes it from sibling disconnect tools that target single instruments.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no explicit when-to-use guidance or comparison to alternative instrument-specific disconnect tools. The 'all active' phrasing implies a global cleanup use case, but the description doesn't state it explicitly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint=true and destructiveHint=false, so the description needs only add context beyond that. It adds the detail that the tool returns 'declared connection interfaces', which clarifies the type of information included. No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence (11 words) that front-loads the verb and resource. Every word earns its place, with no fluff or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, read-only listing tool with an output schema, the description is complete. It states exactly what is listed and includes the key qualifier 'declared' to indicate the nature of the returned data. No further context is necessary.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so schema coverage is 100% by definition. The description does not need to explain parameters; the baseline of 4 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists supported device models and their declared connection interfaces, using a specific verb ('List') and resource ('supported device models'). It distinguishes itself from siblings like list_visa_instruments (which enumerates connected instruments) and identify_instrument (which identifies a single device).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for discovering device model capabilities but provides no explicit when-to-use or alternatives. There is no mention of when to choose this over list_visa_instruments or how it fits into a connection workflow, though the name and purpose make the basic intent clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and destructiveHint false, and the description adds a meaningful behavioral detail: 'without probing them' indicates no instrument interaction. This goes beyond the structured annotations by clarifying the non-invasive nature of the operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single focused sentence that directly states the tool's purpose and key constraint. Every word 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.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple diagnostic tool with no parameters, safe annotations, and an output schema, the description fully conveys what the tool does. It specifically names the relevant hardware (CH340/CH341) and the mapping target (VISA ASRL), making the context complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so there is nothing to document beyond the empty schema. A baseline of 4 is appropriate because there is no parameter complexity requiring additional description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Match' with clear resources ('connected CH340/CH341 ports' to 'VISA ASRL resources'), making the tool's function unambiguous. It also differentiates from siblings like list_visa_instruments by specifying a targeted mapping without probing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'without probing them' implies a safe diagnostic context, giving some usage guidance. However, it does not explicitly state when to prefer this over alternatives or mention any exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses a key behavioral trait: it selects the waveform without enabling the front-panel output. Given that annotations provide no safety hints (all false), this added detail is valuable. However, it does not mention potential side effects or prerequisites (e.g., whether a waveform must already be uploaded), so it is not fully transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that immediately communicates the action and its key caveat. Every word adds value, with no redundancy or unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple no-parameter tool, the description covers the essential action and the important behavioral nuance (not enabling output). However, it leaves implicit that a waveform must already be loaded into volatile ARB memory, and does not mention what happens if none is present. This is a minor gap given the simplicity of the operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the description is not required to explain parameter meanings. The baseline for 0-parameter tools is 4, and the description adds no confusion or missing information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Select') and a clear resource ('the waveform in volatile ARB memory'), and explicitly distinguishes itself from output-enabling actions by stating it does so 'without enabling the front-panel output'. This clearly differentiates it from siblings like 'afg2125_set_output' or 'afg2125_upload_arbitrary_waveform'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context: this is for selecting an already-uploaded waveform in volatile memory, and it explicitly notes that it does not enable the output. It does not name alternative tools or provide explicit when-not-to-use guidance, but the context is strong enough that the intended use case is evident.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=false and destructiveHint=false, consistent with a state-changing toggle. The description adds value beyond annotations by revealing the condition that MAIN output must be disabled, which is a meaningful behavioral constraint not captured in the structured data.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence with no redundant words. It front-loads the action and resource, then adds the conditional context efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-boolean-parameter toggle, the description is largely sufficient. It mentions the key prerequisite (MAIN output disabled) and, given the output schema exists, does not need to detail return values. It could mention prerequisite configuration (e.g., calling afg2125_configure_fm first) but this is not essential.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% coverage for the 'enabled' parameter, but the description 'Enable or disable FM' directly maps to the boolean semantics (true enables, false disables). While not explicit about the mapping, it is implied and clear from the tool name and description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: enabling or disabling FM, with a specific condition (while MAIN output is disabled). It clearly distinguishes this from sibling tools like afg2125_set_am_enabled and afg2125_set_fsk_enabled, making the resource and action unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context by indicating the precondition that MAIN output must be disabled. However, it does not explicitly mention alternatives or when not to use this tool, though the name and sibling set make the FM-specific nature obvious.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations do not indicate read-only or destructive behavior, and the description adds that this selection does not trigger auto-output, which is valuable behavioral context. It does not elaborate on other side effects but is sufficient for a simple function selector.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler words. It conveys the core action and a key behavioral distinction in under 15 words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter waveform selection tool with an output schema, the description covers the purpose, the selectable values, and the no-auto-output behavior. It could mention exact input string syntax or prerequisites for user/ARB, 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.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema only defines 'function' as a string with no description or enum, and schema coverage is 0%. The description compensates by enumerating the selectable values (sine, square, ramp, noise, user/ARB), adding essential meaning to the parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the tool selects waveform functions including sine, square, ramp, noise, and user/ARB, and distinguishes itself from auto-output APPLy. This is a specific verb+resource+scope that clearly defines its purpose relative to siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'without using auto-output APPLy' implies this tool should be used when the output should not be automatically enabled, providing useful usage context. However, it does not explicitly name alternative sibling tools or state when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds behavioral context beyond the annotations by stating the output must be off and that the tool will verify the protection limit after setting it. This is meaningful additional transparency about the tool's operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single well-structured sentence, front-loading the action and resource, with no redundant or filler content. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple single-parameter operation, the description covers the essential context: the purpose, the unit/range, the output-off prerequisite, and the verification step. An output schema exists to document return values, so additional detail is not required.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With schema description coverage at 0%, the description compensates by indicating the parameter voltage_v is in volts and restricted to 0-30 V. This gives essential meaning to the otherwise bare number parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Set'), the target resource ('voltage protection limit'), the value range (0-30 V), and the condition (while output is off). This distinguishes it from sibling tools like m8811_set_voltage (output voltage) and m8811_set_current (current limit).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'while output is off' provides a clear precondition for when this tool should be used. However, it does not explicitly mention alternatives or when not to use it, but the context is reasonably clear from the wording.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description clearly states the operation (close connection) and its scope (AFG-2125 VISA). No annotations conflict; the description adds context that this tool only affects the AFG-2125 connection. While it doesn't detail side effects, the operation is simple and straightforward.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
A single concise sentence that is front-loaded with the tool's purpose. Every word is meaningful, and there is no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter disconnect operation, the description is complete. An output schema exists, so return values are already specified. The description fully covers what the tool does and its scope.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and the schema is empty. No parameter explanation is needed; the baseline of 4 applies since there are no parameters to document.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Close only the AFG-2125 VISA connection' uses a specific verb ('close') and resource ('AFG-2125 VISA connection'). The word 'only' clearly distinguishes this from sibling disconnect tools for other devices or the generic 'disconnect_instrument'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use this tool: when you need to close the AFG-2125 VISA connection specifically. It does not explicitly mention alternatives or exclusions, but the scope is clear from the 'only' phrasing and the sibling tool names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, covering the safety profile. The description adds a specific list of data fields that will be returned, going beyond the structured annotations by clarifying the scope of the read. It does not describe potential connection requirements or failure modes, but for a simple read capability this is sufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, front-loaded with the verb 'Read', and lists the contained elements efficiently. Every word contributes to the meaning; no filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no parameters, an output schema present, and annotations covering safety, the description fully captures what the tool does. It lists exactly what capabilities can be read, making the tool's behavior clear for an agent. The complexity is low, and the description is complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema is trivially 100% covered. The baseline is 4, and the description appropriately does not attempt to explain parameters since none exist. No additional semantics needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Read' and identifies the resource as the instrument's capabilities, listing concrete data items (model, firmware, options, channels, bandwidth, supported interfaces). This clearly distinguishes it from sibling tools like set/configure operations and other get_capabilities variants for different devices.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when needing device identity and supported features (model, firmware, etc.), which gives clear context. However, it does not explicitly mention exclusions or alternatives like get_settings, nor does it state when not to use it. Without direct comparison to siblings, it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the read-only nature is covered. The description adds useful context by disclosing that the hardware serial number is redacted, which is a behavior not captured by annotations. This adds value beyond structured data.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that is front-loaded with the action ('Return') and resource, with no wasted words. It effectively communicates the essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that there are no parameters, annotations cover the read-only safety profile, and an output schema exists, the description provides sufficient context. It explains the key output detail (redacted serial number) and the scope (M8811 identity), making it complete for this simple tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so the baseline is 4. The description doesn't need to elaborate on parameters; it correctly focuses on the output behavior. No additional parameter explanation is required.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns M8811 identity fields, with a specific verb ('Return'), a resource ('M8811 identity fields'), and a distinctive behavior (redacting the hardware serial number). This distinguishes it from other instrument-identify siblings like 'agilentdsox2012a_identify'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this tool is for retrieving M8811 identity information, and the redaction detail gives a clear use case. It doesn't explicitly mention alternatives or when not to use it, but the M8811 scoping is clear enough among sibling identify tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only state non-read-only/non-destructive hints; the description adds that the output must be off and that the setting is verified by read-back. This adds meaningful behavioral context beyond the structured annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence that front-loads the action and range, then adds the key precondition and verification behavior. Every clause is informative and there is no redundant content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter setter with an output schema present, the description covers the action, range, precondition, and verification. No critical information is missing for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema only defines 'voltage_v' as a number, with no description. The tool description compensates by specifying the valid range 0-30 V and implies the unit is volts, giving the single parameter concrete meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Description states a specific action ('Set 0-30 V') on a specific resource (m8811 voltage) and includes the valid range. It is clearly distinguished from sibling tools such as m8811_set_current and m8811_set_voltage_protection by naming the resource and range.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides a concrete precondition ('while output is off'), giving clear context for when the tool can be used. It does not explicitly name alternative tools or exclusions, but the resource-specific wording makes the intended use unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, covering safety. The description adds the 'connected' requirement and specifies the return type (identity + VISA resource), which provides useful behavioral context beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence with no filler words. Every word adds meaning, and the description is appropriately brief for the tool's simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is a simple read-only identify operation with an output schema present. The description fully covers the tool's purpose and device context; return value structure is handled by the output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With zero parameters, the input schema is empty and fully covered. The description correctly avoids inventing parameter details. Baseline for 0 params is 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Return') and identifies the exact resource ('connected Siglent SDG identity and VISA resource'). It clearly distinguishes from sibling identify tools by naming the Siglent SDG family, making it unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'connected Siglent SDG' implies the tool should be used after a connection is established, providing clear context. It does not explicitly mention alternatives, but the device-specific naming makes the use case obvious.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description reveals that the tool both sets the current limit and verifies by read-back, giving insight into its behavior. Since annotations already mark this as a mutating, non-destructive operation, the added verification detail improves transparency. It does not state what happens if output is on, but this is minor given annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
A single 18-word sentence that includes purpose, precondition, and verification; no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter setter with an output schema, the description covers the what, when, and verification behavior, making it fully adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema only defines current_a as a number with no description. The description compensates by stating the valid range '0-5 A' and implicitly the unit (amperes), making the parameter's intended value clear.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Set'), identifies the resource ('current limit'), and adds scope ('0-5 A'), clearly distinguishing it from sibling setters like m8811_set_voltage and m8811_set_output.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It specifies the precondition 'while output is off', which tells the agent when the operation is valid. It does not explicitly name alternatives or exclusion cases, but the context is clear enough for selecting this tool among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is clear. The description adds the behavioral constraint that the tool only applies to the 'only connected instrument', which is useful context beyond annotations. No contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence that fronts the core action and immediately follows with usage guidance. Every word earns its place, with no fluff or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter identification tool with an output schema, annotations, and clear usage guidance, the description is fully complete. It explains the tool's purpose, condition, and alternative behavior, requiring no further information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With zero parameters, the baseline is 4. The description doesn't need to explain parameters, and the empty schema is fully covered (100%). No parameter-related ambiguity exists.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Identify' and a clear resource 'the only connected instrument', clearly distinguishing it from per-instrument identify tools and prefixed command tools. It also contrasts with sibling tools like dpo2012b_identify by specifying the tool is for the global connected instrument.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use this tool ('Identify the only connected instrument') and when to use alternatives ('use prefixed tools when both are connected'). This provides clear context and a direct exclusion, giving the agent unambiguous guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
GitHub Badge
Glama performs regular codebase and documentation scans to:
- Confirm that the MCP server is working as expected.
- Confirm that there are no obvious security issues.
- Evaluate tool definition quality.
Our badge communicates server capabilities, safety, and installation instructions.
Card Badge
Copy to your README.md:
Score Badge
Copy to your README.md:
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
MCP directory API
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/1622352030/lab-equipment-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server