SCPI MCP

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.1.0
Disambiguation4/5
Device-specific prefixes (arb_, dmm_, osc_, psu_) cleanly separate tools by instrument, and most tools target a unique parameter. A few pairs like dmm_read vs dmm_measure and psu_get_voltage vs psu_measure_voltage have overlapping semantics, though descriptions clarify the distinction.
Naming Consistency4/5
Most tools follow a consistent device_verb_noun pattern (e.g., arb_set_frequency, psu_measure_current), making the set highly predictable. Minor deviations such as osc_screenshot, psu_recall, and arb_get_basic_waveform break the strict pattern but are still understandable.
Tool Count3/5
76 tools is a high number, but the server covers four independent instruments with 15-22 tools each, matching the device-specific scope. The count feels heavy for an agent to sort through, though naming conventions and prefix grouping mitigate the burden.
Completeness4/5
The surface covers the vast majority of operations needed for the four instruments: waveform generation, DMM measurement and statistics, oscilloscope triggering/measurement, and PSU output/protection. The most notable gap is lack of oscilloscope waveform data acquisition (raw trace points), which agents may need for signal analysis.
Average 3.6/5 across 76 of 76 tools scored. Lowest: 2.7/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 2 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
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.json to 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?
No annotations are present, so the description carries the full burden of behavioral disclosure. It only says the resolution is set; it does not mention valid values, units, side effects on measurements, persistence, or whether a reset is needed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded, but the Args section is redundant with the schema and does not earn its place. It is concise without being substantively informative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter setter with no annotations and zero schema coverage, this description is not complete enough. Without documenting what values are valid or what effect resolution has on measurement behavior, an agent cannot safely choose the correct argument.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, yet the description's only parameter guidance is 'resolution: Resolution value,' which is a tautology and adds nothing beyond the schema's number type and title. The agent receives no units, bounds, or acceptable value ranges.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific action ('Set') and resource ('measurement resolution on the multimeter'), distinguishing it from other DMM tools like dmm_set_range or dmm_set_nplc. It does not define what 'resolution' means in instrument terms, but the core purpose is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this tool should be used whenever the resolution needs to be configured, and it gives no misleading exclusions. However, it provides no guidance on how resolution relates to range, NPLC, or auto-range alternatives, leaving the agent without a clear selection heuristic.
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?
No annotations are provided, so the description carries the full behavioral-disclosure burden. It only restates the action and argument meanings; it does not mention whether the offset is applied immediately to a channel, what range/validation applies, or what the response contains. For a mutating instrument-control call, this is 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded: one clear action sentence followed by a minimal Args list. There is no filler, repetition, or unrelated context. It is appropriately sized for a simple setter, though it is sparse in other dimensions.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Both required parameters are documented and an output schema exists, so the basic call shape is covered. However, the description lacks range/validation details and gives no guidance on when this tool is the right choice among the many arb_set_* siblings. In an instrument-control context, that missing operational context prevents the agent from being fully confident.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has zero property descriptions, so the description must compensate entirely. It does add useful meaning: channel is explicitly constrained to 1 or 2, and offset is given in volts. However, it does not document any offset range or cross-parameter limitations, so the compensation is only partial.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The opening sentence is a complete verb+object statement: 'Set the DC offset in volts on the waveform generator.' It specifies the instrument, the parameter, and the units, which is enough to distinguish it from other arb_set_* tools without naming them. It does not explicitly contrast with any sibling, so it stops just short of a full 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool instead of related setters like arb_set_amplitude, arb_set_phase, or arb_set_waveform. No prerequisites, channel-state requirements, or conditions are mentioned. An agent is left to infer selection solely from 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?
No annotations are present, so the description carries the full burden of behavioral disclosure. It states only that the trigger mode is set, without saying what effect each mode has on acquisition, whether a running acquisition is stopped or reset, or whether any prerequisites apply. For a state-changing tool with zero annotation coverage, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two tight units: a one-line purpose statement followed by the parameter detail. There is no filler, and the most important information is front-loaded before the Args section.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With one required parameter and an output schema present, the basic call shape is minimally represented, but the description omits behavior and sequencing context, such as whether STOP halts the current acquisition or whether SINGLE requires an arming step. An agent cannot tell from this description how best to use the tool among the many oscilloscope-trigger-related siblings.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema defines 'mode' only as a plain required string, so the description adds real value by enumerating the four allowed values: AUTO, NORM, SINGLE, STOP. However, it does not explain the meaning or behavior of each mode, so it only partially compensates for the 0% schema description coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly names the action ('Set'), the resource ('oscilloscope'), and the target ('trigger mode'), and it lists the valid mode values. It distinguishes itself from trigger-source/level/slope siblings by the word 'mode', though it does not explicitly contrast them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus related siblings such as osc_set_trigger_source, osc_force_trigger, or osc_single. The mode enumeration hints at configuration intent but does not explain contextual situations like when to choose SINGLE over STOP or AUTO.
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?
No annotations are provided, so the description carries the full behavioral disclosure burden. It does not explain what enabling burst mode does to current settings, whether it overrides other modes, requires an enabled output, or takes effect immediately.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise and front-loaded with the primary action. The Args block is cleanly organized and every line contributes useful semantic detail without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple setter with three required parameters, the action and parameters are documented adequately. However, the lack of behavioral context, no mention of the disabling counterpart, and no annotations leave the agent without guidance on side effects or when to choose this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the Args block compensates by adding meaning: channel is scoped to 1 or 2, cycles is defined as burst cycles, and period is given in seconds. This goes beyond the bare property names in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb and resource: 'Enable burst mode on the waveform generator.' It identifies the tool as a burst-mode enable action and is distinguishable from the sibling arb_disable_burst, though it does not name that alternative explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives like arb_disable_burst, arb_set_sweep, or modulation controls. The description states only the action and parameters, leaving usage decisions entirely to inference.
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 no annotations, the description must carry the full burden of behavioral disclosure. It says 'Configure and take a single measurement' but does not reveal whether the configuration persists, whether a trigger is required, whether the call blocks until a reading is ready, or what side effects occur on instrument 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences with a clearly structured Args section. Every element adds necessary information, and there is no redundant or filler language.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter tool with an output schema, the description provides enough to make a plausible call. However, it lacks behavioral context such as side effects and does not clarify its relationship to the many sibling DMM operations, leaving meaningful ambiguity for an agent choosing among set_function, read, fetch, and trigger.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides only a bare string type for 'function' with no enum or description, but the description lists all accepted values: VOLT:DC, VOLT:AC, CURR:DC, CURR:AC, RES, FRES, FREQ, PER. This significantly compensates for the 0% schema description coverage and makes the parameter actionable.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific combined action: 'Configure and take a single measurement on the multimeter,' which clearly identifies the verb and resource. However, it does not explicitly differentiate this from closely related siblings such as dmm_set_function, dmm_read, or dmm_fetch, so it stops short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use dmm_measure instead of dmm_set_function, dmm_read, dmm_fetch, or dmm_trigger. The 'Args' section only lists valid function values, with no mention of prerequisites, setup steps, or when not to use 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?
No annotations are present, so the description carries the full burden of behavioral disclosure. It never explains what auto-setup actually does, whether it overwrites current oscilloscope settings, or whether it has side effects. This leaves significant ambiguity for an agent evaluating the tool's impact.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence with no filler: the verb and resource are immediately clear, and the sentence is appropriately short for a zero-parameter operation. Every word contributes meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple and has an output schema, but the description does not convey what auto-setup configures or when it should be used. Given no annotations and no additional context, an agent receives minimal information beyond the tool name itself, leaving a noticeable gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With zero parameters, there is no semantic burden on the description; the input schema already covers everything. The baseline of 4 for zero-parameter tools applies because there is nothing missing.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb ('Run') and resource ('auto-setup on the oscilloscope'), so the core action is identifiable. It does not explicitly differentiate itself from sibling oscilloscope tools, but 'auto-setup' is a distinct operation and the description is not a mere tautology.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to invoke this tool versus alternatives such as osc_set_timebase or osc_set_trigger_mode. No prerequisites, exclusions, or situational context are given, so an agent must infer usage entirely from 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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states the literal action and does not mention side effects, whether the force is a one-shot event, whether it depends on the oscilloscope's run state, or what happens to acquisition afterward.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single clear, front-loaded sentence with no fluff or repetition. For a zero-parameter command, this is an appropriately minimal and well-structured definition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The empty parameter schema and presence of an output schema reduce the amount of documentation needed, so the action is basically callable. However, with no annotations and no usage context, the description leaves operational questions open, such as when forcing is valid and what side effects follow, making it only minimally complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and 100% schema description coverage, so there is no parameter documentation burden. By the rubric, zero parameters warrant a baseline of 4; the description adds no parameter detail, but none is required.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb ('Force') and a specific resource ('a trigger event on the oscilloscope'). The word 'force' conceptually separates this from the many trigger configuration siblings, but it does not explicitly name or contrast those alternatives, so it stops short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus the many osc trigger-related siblings, nor any mention of prerequisites such as whether the oscilloscope must be running or armed. The only usage signal is the implied action itself, with no exclusions or alternatives described.
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 no annotations provided, the description carries the full behavioral burden, yet it discloses nothing beyond the action name: no mention of the resulting instrument state, idempotency, whether it aborts a wait-for-trigger,or what it returns. An output schema exists, but state-transition semantics remain 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
One eight-word e sentence with zero filler; the action and object are front-loaded and every word earns its place. This is appropriately sized for a zero-parameter tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Minimally viable for a zero-parameter control action with an output schema present, but it leaves clear gaps: no lifecycle context (stopping a continuous run vs. a single acquisition) and no note on whether stopping an already-stopped scope is an error or harmless.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and the empty schema fully covers them, so the baseline for 0 params applies. There is nothing for the description to add about parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Stop') and a specific resource ('acquisition on the oscilloscope'), making the action unambiguous. It does not explicitly contrast with siblings like osc_run or osc_single, but the 'stop' verb is distinctive within the sibling set.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does 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 such as osc_single or osc_force_trigger. The intended context — halting a continuous run or aborting a single acquisition — must be inferred entirely from the sibling list 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?
There are no annotations, so the description carries the full burden for behavioral context. It only restates the action 'Set the output voltage' and does not disclose side effects, whether the output must be enabled, range limits, or whether the setting persists. For a mutation tool, this is a meaningful 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded with the purpose, followed by two terse, useful parameter explanations. There is no filler, redundancy, or unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a low-complexity tool with two simple required parameters and an output schema present, this is near-minimally viable. The missing pieces are usage context and side-effect information, such as whether the channel output must be enabled for the voltage to take effect. The description covers the basics but leaves those operational details to inference.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Even though schema_description_coverage is 0%, the Args block adds valuable meaning: channel is constrained to 1, 2, or 3, and voltage is specified in volts. This goes beyond the bare integer/number types in the schema. It does not provide range limits or additional constraints, but the provided information is sufficient for basic use.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the operation: 'Set the output voltage on a power supply channel.' This is a specific verb and resource, and it is distinguishable from sibling tools like psu_set_current and psu_get_voltage. However, it does not explicitly name or contrast any sibling, so it misses the differentiating clarity of a top-tier description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does 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 such as psu_set_current, psu_set_output, or psu_measure_voltage. The only usage signal is implicit from the tool name and one-line description, with no mention of prerequisites, output enable state, or when this should be called.
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?
There are no annotations, so the description carries full responsibility for behavior. 'Enable AM modulation' implies a state change but does not say whether it overwrites existing modulation, interplays with FM/PM, requires a carrier waveform, or has any side effects. This is too thin for a state-changing instrument command.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely compact and front-loaded: one purpose sentence followed by a concise parameter list. Every line provides necessary information with no filler or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a setter with no annotations and zero schema description coverage, the description is too minimal. It lacks behavioral context, valid ranges, return value meaning despite an output schema, and guidance on how this relates to other modulation tools. An agent would have to guess about side effects and interactions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so parameter meaning depends entirely on the description. It compensates well by adding units ('percent', 'Hz') and the valid channel range ('1 or 2'), going beyond bare schema property names. It does not give valid ranges for depth or frequency, but the essentials are clearly defined.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('Enable AM modulation') on a clear resource ('the waveform generator'), which separates it from the many sibling tools. It does not explicitly name or distinguish against arb_set_fm or arb_set_pm, but the AM-specific wording is unambiguous enough.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The first sentence implies the use case: use this when you want to enable AM modulation on the generator. However, it provides no explicit when-not-to-use guidance or alternatives such as FM, PM, or sweep modulation, leaving the selection decision partially to inference.
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?
No annotations are provided, so the description carries the full burden. It reveals the action type but not behavioral consequences: whether the trigger is synchronous, whether the device must be armed, or any side effects on pending measurements. This is thin 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence that states the action and target with no filler. Every word contributes to the meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a parameterless trigger action, the description is largely sufficient: an agent knows what the tool does and what to invoke. However, it omits prerequisites like trigger source configuration, which a more complete context would include.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the empty input schema is complete. The description adds no parameter-specific information but none is needed; the baseline of 4 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb ('Send'), resource ('software trigger'), and target ('multimeter'). It is clear enough to distinguish from instrument configuration tools like dmm_set_trigger_source, though it does not explicitly mention the analogous osc_force_trigger sibling.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives. It does not mention relationships to dmm_set_trigger_source, dmm_read/fetch, or when a software trigger is appropriate in a measurement workflow.
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 no annotations provided, the description carries full burden for behavioral disclosure. 'Query' implies a read-only operation, but it does not explain what the returned status contains, whether it affects the instrument, or any other side-effects, leaving the agent with limited insight beyond the name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, compact sentence that states the operation and adds just enough detail in parentheses. Every word earns its place; no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a parameterless read-only query, the description is largely sufficient, especially because an output schema exists and the tool is simple. However, it does not place the tool within its sibling family or mention when it should be invoked, so a bit of context is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema is empty, so there is no parameter semantics to document. The baseline of 4 applies because the description is not required to compensate for any undocumented parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Query') and a clear resource ('system status register'), and it adds parenthetical detail ('channel modes, output states') that hints at its scope. This distinguishes it from related tools like psu_get_voltage or psu_get_output, though it does not explicitly name a sibling or draw a contrast.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to prefer this tool over alternatives such as psu_get_output or psu_get_voltage. There is no mention of use context, prerequisites, or exclusions, leaving the agent to infer the right situation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure, but it only states the action without covering side effects, whether modulation settings are reset, or any instrument prerequisites. It also leaves 'all modulation' undefined in terms of which specific modulation modes are affected.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact, front-loaded with the main action, and contains no unnecessary filler. The argument documentation is minimal but directly useful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter command with an output schema available, the description gives the core action and channel range. Still, it lacks clarity on exactly which modulation modes are disabled and any side effects, so an agent may not fully understand the tool's scope without additional inference.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate, and it does by explaining that channel is 1 or 2. This adds the key constraint beyond the bare integer schema, though it omits details like error behavior or whether channel is 1-indexed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific action ('Disable all modulation') and resource ('waveform generator channel'), so the agent understands the core operation. It does not explicitly enumerate which modulation types are included (AM/FM/PM vs sweep/burst), leaving slight ambiguity against sibling disable 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool: when all modulation on a channel should be turned off. However, it provides no explicit when-not-to-use guidance and does not differentiate itself from arb_disable_sweep or arb_disable_burst.
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 no annotations provided, the description carries the full burden. The word 'Query' plus 'current' implies a read-only, live read with no mutation side effects, which is useful. However, it does not disclose error behavior, what happens on an invalid channel, or any other operational details beyond the basic read nature.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded: the purpose appears in the first sentence, followed by a concise argument explanation. Every sentence contributes value and there is no filler or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has only one parameter, the channel constraint is documented, and an output schema exists, the description is close to adequate. However, it does not clarify what 'basic waveform parameters' actually include nor provide any usage guidance, so an agent may still be uncertain about when this tool is the right choice.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema only specifies an integer channel, while the description adds the meaningful constraint 'Channel number (1 or 2)'. This is valuable semantic information beyond the raw schema. It still leaves room for more detail such as default or invalid-channel behavior, but it fully addresses the one required parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Query' and names the resource: 'current basic waveform parameters of a waveform generator channel'. This clearly identifies a read operation and distinguishes it from the many arb_set_* sibling tools, though it does not explicitly call out sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given about when to use this tool versus alternatives such as arb_set_waveform or arb_get_output. The read-versus-write contrast is implied by 'Query', but there are no explicit conditions, 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?
With no annotations, the description must disclose behavioral traits. It states only that the tool changes acquisition mode and gives no information about side effects, prerequisites, interaction with averaging, or whether the change takes effect immediately.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short, front-loaded with the purpose, and contains no filler. The argument documentation is compact, though it could be slightly more structured with a bulleted list.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter setter this is minimally adequate: it names the operation and valid inputs. However, it lacks practical context such as the relationship between AVERAGE mode and osc_set_average_count, and whether the instrument needs to be in a particular state.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema only defines mode as a generic string with no enum, so the description adds the essential valid values (SAMPLING, PEAK_DETECT, AVERAGE). This compensates for the 0% schema coverage, though it does not explain the meaning of each mode.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action and object: it sets the oscilloscope's acquisition mode. This clearly differentiates the tool from sibling setters like osc_set_timebase or osc_set_trigger_mode.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given about when this tool should be chosen, when it should not be used, or how it relates to alternatives such as osc_set_average_count. The only usage cue is implied by the tool's name and first sentence.
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 no annotations, the description carries the full burden of behavioral disclosure, but it only states 'Recall a saved preset' without mentioning side effects, whether current settings are overwritten, output state changes, or failure modes. This is a mutation-like operation with no behavioral detail.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single leading sentence followed by a compact Args line. Every word earns its place, the action is front-loaded, and there is no filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given 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 is short but missing important context: no prerequisites, side effects, or relation to psu_save are mentioned. With no annotations and only an output schema, the behavioral context remains under-specified for an agent to invoke this correctly in all situations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema only defines 'preset' as an integer with no description. The description adds 'Preset number (1–5)', giving the parameter clear meaning and a validation range. With 0% schema description coverage, this adequately compensates for the schema gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('Recall') on a specific resource ('a saved preset on the power supply') and provides the valid range (1–5), making it distinct from sibling tools like psu_save. An agent can tell what this tool does without inspecting the schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No when-to-use or alternative guidance is provided. The description only defines the action and does not contrast with psu_save or other psu_set_* commands, nor mention prerequisites such as an existing saved preset.
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?
It discloses a useful behavioral trait: commands ending with '?' return a response, implying non-query commands may not. However, with no annotations, the description carries the full burden and does not mention that arbitrary commands can have side effects, risk device state changes, or produce errors/timeouts.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact, front-loaded with the core purpose, and uses a clearly structured Args block. Every sentence contributes useful information without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The essential parameter values and the query-response convention are covered, and an output schema likely handles return-value documentation. Still, for a tool with no annotations, it lacks guidance on when to prefer it over siblings and does not warn about the potential consequences of sending arbitrary SCPI commands.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the Args block adds crucial meaning: it enumerates the valid device keys ('arb', 'dmm', 'osc', 'psu') and explains that command is the raw SCPI string. It could go further with format examples or syntax caveats, but it compensates well for the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: sending an arbitrary SCPI command to a device, with a clear note about query commands returning responses. The word 'arbitrary' and 'raw' signal a low-level escape hatch, distinguishing it from the many high-level sibling tools, though it does not explicitly name them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does 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 the many specific sibling tools such as dmm_read or osc_set_timebase. The phrase 'arbitrary SCPI command' implies it is a fallback, but there is no clear 'use only when no dedicated tool exists' instruction.
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?
No annotations are provided, so the description carries full responsibility for behavioral disclosure. It states only the core action and channel, with no mention of side effects, whether the channel output remains enabled, what state is left behind, or whether an error occurs if sweep was never enabled.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one clear sentence followed by a minimal, useful Args section. No filler or redundant restatement of the tool name, and the key action is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter tool, the purpose and parameter are adequately covered. However, with no annotations and no mention of usage context or behavioral side effects, the description is only minimally complete. An agent would know what the tool does but not when or how it fits into a sweep setup workflow.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides only the parameter name 'channel' with no description, and schema_description_coverage is 0%. The description compensates by explicitly stating 'Channel number (1 or 2),' adding the valid range that the schema does not convey. This is sufficient for the single parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action and resource: 'Disable frequency sweep on a waveform generator channel.' It clearly differentiates from siblings like arb_set_sweep, arb_disable_modulation, and arb_disable_burst by naming the exact feature being disabled.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance about when to use this tool versus alternatives. It is implied that you call it when you want to disable sweep, but there is no mention of prerequisites, interaction with arb_set_sweep, or whether it should be used before disabling modulation or 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?
With no annotations, the description carries the full burden of behavioral disclosure. It states the action and units but does not mention side effects, error behavior, valid ranges, or whether the setting is immediate/persistent. 'Set' implies mutation, but nothing is disclosed about what happens on invalid input or whether the change requires the output to be enabled.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely efficient: one imperative sentence followed by two short parameter lines. The main action is front-loaded, and there is no filler or repetition of schema structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a two-parameter tool with an output schema, the description covers the core operation and parameter semantics. However, it omits practical details an agent needs for correct use, such as amplitude limits, channel validation, and whether the output must be enabled. These are notable gaps but not crippling given the simple signature.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Since schema description coverage is 0%, the description compensates by explaining channel as 'Channel number (1 or 2)' and amplitude as 'Amplitude in Vpp'. This adds real value beyond the raw integer/number types in the schema. No minimum/maximum amplitude constraints are given, but the key semantics are covered.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description starts with the verb 'Set', names the resource 'output amplitude', specifies the unit 'Vpp', and identifies the target device 'waveform generator'. This clearly distinguishes it from sibling setters like arb_set_offset or arb_set_output_load.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description offers no guidance on when to use this tool versus alternatives, nor does it mention prerequisites like valid amplitude range, output enable state, or when this setter should be preferred over similar set functions. The context is only implied by the tool name and sibling set values.
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 no annotations provided, the description carries the full burden of behavioral disclosure. It states the primary action and parameters, but does not disclose side effects such as whether enabling FM modulation modifies the currently selected waveform, overrides other modulation modes, or takes effect immediately on the output.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single clear statement followed by a compact, well-formatted Args list. Every line earns its place, and the most important semantic details are front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple three-parameter configuration tool, the description and schema together provide the core invocation details. However, the lack of usage guidance and behavioral side-effect disclosure means an agent does not fully understand what happens to the instrument's output when FM is enabled, so the definition is adequate but not complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides no property descriptions (0% coverage), but the description compensates by defining each parameter: channel is restricted to 1 or 2, deviation is in Hz, and frequency is in Hz. This gives the agent the units and channel constraint necessary to invoke the tool correctly, though numeric ranges or valid limits are not provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Enable') and a clear resource ('FM modulation on the waveform generator'), which unambiguously distinguishes this from sibling tools like arb_set_am, arb_set_pm, and arb_set_sweep. It states exactly what action the tool performs without ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no explicit guidance on when to use this tool versus alternatives such as arb_set_am, arb_set_pm, or arb_disable_modulation. No prerequisites, exclusions, or alternative routing are mentioned, leaving the agent to infer usage context from the tool name and sibling list.
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?
There are no annotations, so the description carries the full burden of behavioral disclosure. It only says 'set' the frequency; it does not mention whether this immediately affects a running output, requires the output to be enabled, or interacts with modulation/sweep settings. For a state-changing instrument operation, this is a noticeable 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely compact: two sentences plus two argument bullets. Every line earns its place, and the primary verb-resource-unit statement is front-loaded. There is no filler or repetition of schema content beyond what is helpful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a low-complexity setter with two scalar parameters, the description covers parameter semantics well and an output schema exists, so return-value documentation is not the description's job. However, the absence of any behavioral context (side effects, dependencies, or when not to use) leaves the definition merely adequate rather than fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaning beyond the bare schema by specifying that channel must be 1 or 2 and that frequency is expressed in Hz. The schema only provides integer/number types, so this extra constraint and unit information is genuinely useful for correct invocation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('Set the output frequency'), the resource ('waveform generator'), and the unit ('in Hz'), making the tool's function immediately clear. It also distinguishes itself from sibling tools like arb_set_amplitude or arb_set_waveform by naming exactly which parameter is being configured.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance about when to use this tool versus alternatives, no preconditions, and no exclusions. While the name and sibling set strongly imply it is for frequency changes, there is no explicit context such as 'use when the output is already configured' or 'not valid during sweep/modulation modes.'
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?
There are no annotations, so the description carries full behavioral disclosure burden. It only says 'set the phase' and lists parameters; it does not describe side effects, whether the output must be enabled, or error behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact: one action sentence and a minimal two-item Args list. No filler or repetition; every line contributes information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter setter, the core call semantics are adequately defined. However, without annotations or usage guidance, the agent lacks context about side effects and when to choose this tool versus related setters, so it is not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides only property names/types with no descriptions, so the description compensates by explaining that channel is 1 or 2 and phase is in degrees. This is essential for correct invocation, though it could add ranges or interaction details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
States exactly what it does: sets the phase in degrees on the waveform generator. The resource and action are specific, and the phase focus clearly separates it from sibling tools like arb_set_frequency or arb_set_amplitude.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No when-to-use guidance is provided. It does not mention alternatives or cases where another arb_set_* tool would be more appropriate, leaving the agent to infer usage from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are absent, so the description carries full responsibility for behavioral disclosure. It only says "Enable PM" and does not mention whether enabling PM disables other modulation modes, whether output must be enabled, 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded with the purpose, followed by a clean Args list. It contains no filler or redundant content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple instrument command, the intent and parameter semantics are present, and an output schema exists. However, it lacks usage context, valid numeric ranges, and interaction with other modulation settings, so the agent is left to make some assumptions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but the description compensates by adding meaning to all three parameters: channel range (1 or 2), deviation unit (degrees), and frequency unit (Hz). It does not provide valid numeric ranges, but it gives the essential semantics needed to invoke the tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
States "Enable PM (phase) modulation on the waveform generator," which is a specific verb and resource. The parenthetical disambiguates PM as phase modulation, differentiating it from sibling AM/FM modulation 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given about when to use this tool versus alternatives such as arb_set_am, arb_set_fm, or arb_disable_modulation. Usage must be inferred from the tool name and description alone.
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 no annotations, the description carries the full burden. It states the main behavior: accumulated statistics are cleared. However, it does not disclose whether this is irreversible, whether statistics must be enabled first, or whether any other multimeter settings are affected.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single clear sentence with no filler or redundancy. It is appropriately sized for a zero-parameter operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter tool with an output schema, this is nearly complete. It conveys the essential operation, but it does not mention whether statistics need to be enabled or whether all statistical fields are cleared, which would strengthen the definition slightly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and 100% schema coverage, so the baseline is 4. There are no parameter meanings to explain, and the description does not need to compensate for any schema gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Clear accumulated statistics on the multimeter' uses a specific verb and resource, clearly distinguishing it from get/enable/disable statistics tools. It does not explicitly clarify that it only clears statistics and performs no other reset behavior, but the meaning is largely 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus siblings like 'reset' or dmm_get_statistics. The description simply restates the function without providing context, prerequisites, or 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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only restates the disabling action and does not mention whether existing statistics are preserved or cleared, whether it affects subsequent measurements, or whether any precondition applies. This is a common gap for a state-changing tool with no annotation support.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler or repetition. For a zero-parameter tool, this is an appropriately concise and structured definition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the zero parameters and presence of an output schema, the description is close to sufficient. However, it omits the practical relationship to dmm_enable_statistics and whether disabling statistics retains or discards previously gathered data. This is a minor but real gap for a state-changing DMM command.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema is empty, so there are no parameter semantics to explain. Per the rubric, a zero-parameter tool receives a baseline of 4, and the description adds no unnecessary parameter-related noise.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Disable') and a clear resource ('statistics calculation on the multimeter'), directly matching the tool name and distinguishing it from sibling tools like dmm_enable_statistics. It is not a tautology and immediately conveys 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 Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance about when to use this tool versus alternatives such as dmm_enable_statistics, dmm_clear_statistics, or dmm_get_statistics. The agent must infer usage entirely from the tool name and one-line description, with no explicit context or 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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only states the action 'enable' and does not explain whether statistics persist, whether previous statistics are cleared, what side effects occur, or what the tool returns.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no filler. The verb and object are front-loaded, and the length is appropriate for a zero-parameter state-change command.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter tool with an output schema, the invocation surface is minimal and the description is syntactically sufficient. However, it leaves the broader statistics workflow underspecified—such as when to enable statistics, how it interacts with dmm_measure, and how it relates to get/clear/disable statistics.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the schema fully covers parameter needs. Per the rubric, a 0-parameter tool receives a baseline of 4; no additional parameter information is necessary.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'Enable statistics calculation on the multimeter.' This clearly identifies the operation and distinguishes it from siblings like dmm_disable_statistics and dmm_get_statistics.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool versus the related statistics tools, nor does it mention prerequisites or ordering relative to measurement or statistics retrieval. Usage must be inferred entirely from the tool name and sibling set.
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 no annotations, the description carries the full behavioral burden. It usefully discloses that the tool triggers the instrument and then reads a new measurement. However, it does not mention whether the call blocks until the measurement is stable, what happens on trigger failure, or any other 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with a useful parenthetical clarification. There is no wasted text, though it is brief enough that some usage and behavior details are left out.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is adequate for a zero-parameter tool with an output schema. However, the presence of siblings such as dmm_measure, dmm_fetch, and dmm_trigger means an agent could still struggle to select the correct tool without explicit routing or differentiation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the schema already fully covers parameter semantics. The description does not need to add parameter details, and the no-parameter baseline of 4 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action and resource: 'Take a new measurement reading from the multimeter', and clarifies that it 'triggers and reads'. It is clear about what the tool does, but does not explicitly distinguish it from closely related siblings like dmm_measure or dmm_fetch.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The parenthetical 'triggers and reads' implies when this tool should be used: when a fresh, triggered reading is needed. However, there is no explicit guidance about alternatives or when not to use it, which matters given the many similar DMM sibling tools.
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 absent, so the description carries the full burden. It only says the range is set and gives an example; it does not address interaction with auto-range, units relative to the currently selected measurement function, or handling of invalid values. For a mutating instrument-control tool, this is a meaningful 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded and compact: a one-sentence operation statement followed by a small Args block. There is no filler, repetition, or re-listing of schema-only facts.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter setter with an output schema, the basics are present: operation, scope, and parameter meaning. However, it leaves out range constraints, unit applicability across measurement functions, and the relationship to auto-range, so it is adequate but not fully self-sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema only says 'value' is a number with no description, and schema description coverage is 0%. The description compensates by defining value as a range value and providing a unit-based example ('10 for 10V range'), which is genuinely useful for a single-parameter tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb ('Set') and resource ('measurement range on the multimeter'), with a concrete value example. This is clearly distinguishable from siblings like dmm_get_range (read) and dmm_set_auto_range (automatic mode).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does 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. It never mentions dmm_set_auto_range or the conditions under which manual range setting is appropriate, leaving the agent to infer usage from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states that the trigger source will be set but does not mention whether this affects pending measurements, whether it persists across device resets, whether certain modes are required, or what happens with an invalid source. For a mutating configuration command, this leaves notable 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, front-loading the core purpose in the first sentence and then enumerating the parameter value in a clean Args block. Every sentence contributes needed information without redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter setter, the description covers the essential invocation details and the output schema exists, so return-value documentation is unnecessary. However, it omits the meaning of IMM/BUS/EXT and how this setting interacts with dmm_trigger or dmm_read, which an agent would need to make a fully informed call. It is adequate but has clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema only defines 'source' as a string with no enums or details, and schema description coverage is 0%. The description compensates by explicitly listing the allowed values: IMM, BUS, EXT. It does not explain the meaning or selection context of each value, but it provides the critical constraint that the schema is missing.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action: 'Set the trigger source on the multimeter.' This clearly identifies the verb, resource, and device, and distinguishes it from other trigger-related tools like dmm_trigger and osc_set_trigger_source. The allowed source values are also included, making the tool's intent 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as dmm_trigger or other DMM configuration tools. It does not mention prerequisites, sequencing with dmm_trigger, or exclude cases where another trigger-setting method is appropriate. The usage context 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. The word 'Query' conveys a read-only operation, and 'full channel setup info' suggests it returns a comprehensive snapshot, but it does not mention error behavior, invalid channel handling, or whether the channel must be enabled.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short and front-loaded with the operation and resource. The Args section is minimal and contains no filler, making it easy for an agent to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is a simple one-parameter getter with an output schema available, so the description does not need to explain return values. It captures the core behavior and the only argument's valid range; the main gap is the lack of any usage-boundary context, but that is minor given the low complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema only says the parameter is an integer, while the description adds the key constraint that channel must be 1 or 2. This meaningfully compensates for the 0% schema description coverage, though it does not explain the semantic difference between channels.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb ('Query'), a specific resource ('full channel setup info'), and the target instrument ('oscilloscope'). It is immediately distinguishable from setters and other getters, though it does not explicitly name sibling tools to rule out confusion.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does 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, such as osc_get_timebase or the channel configuration setters. There are also no prerequisites or conditions stated beyond the basic channel argument.
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?
No annotations are provided, so the description must carry the behavioral disclosure burden. It usefully states that the result is base64-encoded PNG data, and 'capture' implies a non-mutating read operation. However, it does not disclose side effects, state requirements, or whether the screenshot represents the current display state beyond the name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that front-loads the action and includes the essential return format. There is no filler or redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-argument tool with an output schema, the description covers the core purpose and return encoding. It lacks usage context and state prerequisites, but the overall complexity is very low, so the description is nearly complete for practical invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so there is nothing for the description to explain about parameter meanings. The empty schema is self-explanatory, and no parameter-level guidance is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Capture') and identifies the resource ('screenshot from the oscilloscope'), making the tool's purpose obvious. It also states the return format as base64-encoded PNG. It does not explicitly distinguish itself from sibling tools, but the action is unique and unambiguous among the sibling list.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, no prerequisites, and no exclusions. An agent must infer entirely from the name that this is for capturing a screen image, with no context about when a screenshot is appropriate or whether the oscilloscope needs to be in a specific state.
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?
No annotations are provided, so the description carries the full burden of disclosing behavior. It indicates that the tool mutates instrument state by 'Set', but it does not disclose side effects, validation behavior, whether the channel must be active, or what happens on invalid input. This is minimal, similar to other mutation tools with no annotation support.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is only two lines plus an Args block, every part earned its place. The purpose is front-loaded and the parameter descriptions are concise and useful. There is no tautology or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a two-parameter setter with an output schema, this is mostly complete: both parameters are explained clearly. Missing pieces include valid scale boundaries and any behavioral context such as whether the instrument must be stopped or whether the setting takes effect immediately. That leaves a noticeable gap for an agent that must call the tool correctly in an actual session.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It does: 'channel' is specified as 1 or 2, and 'scale' is specified as volts per division. This adds real meaning beyond the bare integer/number schema. It stops short of giving a valid range for scale, so it misses a perfect score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'Set the vertical scale (V/div) of an oscilloscope channel.' This clearly distinguishes it from siblings like osc_set_channel_offset, osc_set_channel_coupling, and osc_set_timebase by naming the exact instrument 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 Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given about when to use this tool versus alternatives. The description does not mention siblings, prerequisites, or when not to use it. The agent must infer from the tool name and 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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states that the tool sets the trigger slope and explains the POS/NEG value semantics, but it does not disclose whether existing settings are overwritten, whether the change is immediate or persistent, what prerequisites apply, or what happens on unsupported values.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: the purpose is front-loaded in the first sentence, followed by a compact args block. Every line contributes useful information, and there is no filler or redundant restatement of the schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter setter with an output schema, this is largely complete for correct invocation: the target resource, the action, and the accepted value semantics are all present. The main gaps are the lack of alternatives/usage context and limited detail on post-call behavior, but these are not blocking for the tool's core purpose.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides only a string property with no description, enum, or constraints, so the description is the sole source of parameter meaning. It fully documents the only required parameter by mapping 'POS' to rising edge and 'NEG' to falling edge, which is exactly the information an agent needs.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Set the trigger slope on the oscilloscope,' naming a specific action, target instrument, and resource. It clearly identifies the tool's purpose, and the term 'slope' distinguishes it from sibling trigger tools, though it does not explicitly contrast it with them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus sibling tools like osc_set_trigger_mode, osc_set_trigger_source, or osc_set_trigger_level. The only usage-related content is the mapping of slope values to edge directions, which addresses parameter usage rather than 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?
No annotations are present, so the description carries the disclosure burden. It clearly states the state change (sets the oscilloscope to single-trigger mode), but adds no extra behavioral context such as acquisition arming, interaction with osc_run, or side effects. This is minimally adequate for a no-argument setter, 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
One concise, front-loaded sentence with no filler. Every word contributes to meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-argument tool with no required inputs, the description is essentially complete for invoking it correctly. The main gap is not explaining how it relates to osc_set_trigger_mode, but that is more of a usage-guidance issue than a completeness issue.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so the description has no parametric meaning to add. This matches the baseline for zero-parameter tools.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear action ('Set') on a specific instrument ('the oscilloscope') with a concrete target state ('single-trigger mode'). It is not vague, but it does not explicitly differentiate itself from the closely related sibling osc_set_trigger_mode.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The text gives no guidance about when to call this tool rather than siblings such as osc_set_trigger_mode or osc_force_trigger. No exclusions or alternative routing are provided; the only implied cue is the phrase 'single-trigger mode'.
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?
No annotations are present, so the description carries full behavioral burden. It only states that the mode is set, without mentioning side effects, required conditions (e.g., output disabled), or how tracking affects channel behavior. This is a minimal disclosure for a mutating 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded with the purpose, followed by a concise Arg line. Every word is informative, and it avoids repeating schema details while adding the missing enum values.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter setter, the description provides the necessary allowed values and a clear purpose. However, it omits explanation of what tracking mode actually does and any situational context, leaving the agent without enough information to decide which mode is appropriate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema exposes only a string field with no enum or description. The description compensates by listing the three valid values (INDEPENDENT, SERIES, PARALLEL), which is essential for correct invocation. It does not explain the meaning of each mode, but it covers the required input space.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Set') and a clear resource ('channel tracking mode on the power supply'), making the tool's function unambiguous. It distinguishes itself from sibling tools like psu_set_voltage and psu_set_current without confusion.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use tracking mode, what alternatives exist, or any prerequisites or consequences. The agent must infer usage purely from the tool name and the mode list, which is not explicit 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 are absent, so the description carries the full burden of behavioral disclosure. It only says what the tool sets, not whether it applies immediately, whether the output must be disabled, what side effects occur, or what limits apply.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded with the primary action, followed by a clean Args list. Every sentence contributes necessary information without fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter tool, the essential namespace and parameter meanings are present, and an output schema exists. However, as a mutating power-supply operation with no annotations, it lacks behavioral context such as voltage limits, immediate effect, or prerequisite output state.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The Args section adds meaning beyond the raw schema: it specifies channel is 1 or 2 and voltage is in volts. It does not provide a voltage range, but for two parameters with 0% schema coverage, this is solid compensation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('Set the over-voltage protection threshold') on a specific resource ('a power supply channel'). It clearly differentiates from siblings like psu_set_voltage and psu_set_ocp by naming OVP 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/5
Does 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. With sibling tools like psu_set_ocp, psu_set_voltage, and psu_set_current, the description does not state conditions or exclusions that would help an agent choose correctly.
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?
No annotations are provided, so the description carries the disclosure burden. It does state the core behavior as a binary toggle, but it does not mention side effects, persistence, or how auto-range interacts with other DMM settings such as manual range or measurement.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact, front-loaded with the action, and contains no filler. The parameter explanation is minimal and directly useful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple and an output schema exists, so explaining return values is unnecessary. However, with no annotations, the lack of any note about side effects or interaction with related DMM range tools leaves the context slightly incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema only describes 'enable' as a boolean and provides no property descriptions. The description compensates by explicitly mapping True to enable and False to disable, giving the agent the exact semantic needed for the single parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific action ('enable or disable') on a specific resource ('auto-range on the multimeter'), which clearly identifies the tool's function. It does not explicitly contrast with the sibling dmm_set_range, so it does not fully differentiate among the range-related DMM 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The intended use is implied by the action phrase: use this tool when auto-ranging should be turned on or off. However, there is no explicit guidance about when not to use it or when to prefer dmm_set_range for manual range control.
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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. The description merely restates the action in the name and adds the unit; it does not mention side effects, required device state, error behavior, or whether the setting takes effect immediately.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short and front-loaded, with a one-sentence purpose followed by a single parameter line. Every word earns its place and there is no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a low-complexity setter with one required parameter, the description is mostly complete: it names the parameter and its unit. The only notable gap is the absence of any valid-range or operating-condition note, but this is not critical for such a simple tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It does so by explaining that 'level' is the trigger level in volts, which adds meaning beyond the bare schema type 'number'. It lacks a valid range but is otherwise sufficient for a single simple numeric parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Set') with a precise resource ('trigger level') and a unit ('volts'), clearly distinguishing it from sibling trigger tools like osc_set_trigger_mode, osc_set_trigger_source, and osc_set_trigger_slope. An agent can instantly tell what this 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 Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance about when to use this tool versus its trigger-related siblings, no preconditions, and no exclusions. The usage is only implied by the tool name, not explained.
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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the direct effect (enable/disable output) but does not mention behavior for invalid channels, persistence of state, interaction with voltage/current settings, 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: one short purpose sentence followed by two one-line parameter definitions. Every sentence contributes necessary information, and the main action is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter state setter, the description plus input schema provide the essential information needed to call the tool: channel, state, and what the action does. However, missing usage guidance and lack of behavioral nuance around invalid inputs leave it merely adequate rather than fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description fully compensates: 'channel' is documented as 1, 2, or 3, and 'state' is explicitly mapped to True=enabled and False=disabled. This adds concrete semantic meaning beyond the raw schema type names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action, 'Enable or disable the output of a power supply channel,' and identifies both the resource (output) and the scope (specific channel). This clearly distinguishes it from sibling tools like psu_get_output and psu_set_voltage.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance about when to use this tool versus alternatives such as psu_get_output or psu_set_current. The action is implied by the verb, but no explicit conditions, exclusions, or alternative-selection cues 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?
No annotations are present, so the description must carry the behavioral burden. It indicates a mutation ('Set') but does not disclose side effects, prerequisites, or failure behavior. This is sparse but not contradictory.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single clear operation sentence followed by a compact argument list. No filler and the most important constraint values are front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter setter with an output schema available, the description covers both required values and their meanings. Missing lock of preconditions/error expectations is minor for this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides no descriptions for either parameter. The description compensates fully by specifying allowed values: channel is 1 or 2, and polarity is 'NOR' or 'INVT'. This is exactly the call-control information an agent needs.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
States exactly the operation (set) and resource (output polarity on the waveform generator). None of the arb_* sibling tools mentions polarity, so it is clearly distinguishable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives, no preconditions, and no exclusions. The description simply states what it does without giving an agent context for choosing it over other arb_* setters.
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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states that the function is set and lists valid values, but it does not say whether switching functions resets range, interrupts a measurement, or has any other side effect.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded, with the purpose stated first and a compact argument list following. Every sentence 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.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter setter, the description supplies the purpose and all valid inputs, and an output schema exists to handle return-value expectations. It is slightly incomplete only because it omits sequencing context relative to the other DMM tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema is a bare string with 0% description coverage and no enum. The description fully compensates by exhaustively listing all accepted values (VOLT:DC ... CAP), which is the essential semantic information needed to call the tool correctly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('Set') and a clear target ('the measurement function on the multimeter'), and it enumerates the valid function values. This makes the tool's purpose distinct from sibling setters like dmm_set_range and dmm_set_resolution.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives, no prerequisites, and no mention of related tools such as dmm_get_function or dmm_read. The agent must infer usage purely from the tool name and the generic 'Set' statement.
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?
No annotations are present, so the description must carry the full burden of behavioral disclosure. It only states what the tool sets and does not mention valid ranges, device requirements, side effects, error conditions, or whether the setting affects subsequent measurements. This is thin coverage for a configuration mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and efficient: one sentence defines the operation and one line documents the parameter. It is front-loaded with the purpose and contains no filler or redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter setter, the description is mostly adequate, and an output schema exists so return-value details are not required. However, it omits valid range constraints, the effect of the setting, and any prerequisites or behavioral caveats, which leaves gaps for an agent operating without annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema only says 'nplc' is a number, but the description adds meaning by explaining it as the NPLC value in power line cycles and gives concrete examples. This helps the agent understand what value to pass, though it stops short of specifying valid bounds or discrete allowed values.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action: setting the integration time in number of power line cycles on the multimeter. It names both the resource (multimeter) and the setting (NPLC), making it easy to distinguish from sibling tools like dmm_set_resolution or dmm_set_range.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The intended use is implied by the description: use this tool when you need to configure the DMM's integration time. However, no explicit guidance is given about when to prefer this over related settings such as dmm_set_resolution, nor are any alternative tools or exclusions mentioned.
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?
No annotations are present, so the description must carry the behavioral burden. It states the core action clearly and lists valid inputs, but it does not disclose prerequisites, side effects, or behavior on invalid input. Since an output schema exists, return-value details are not required, but the description still lacks operational context such as whether the measurement uses the current displayed acquisition.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded: one clear purpose sentence followed by a tight Args block. The parameter list is long but necessary for correctness, and there is no filler or redundant content. Every element earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a two-parameter instrument read, the description covers the core inputs and the operation name well, and the output schema handles the return value. However, it omits important operational prerequisites such as an enabled channel and a stable/triggered acquisition, and it gives no when-to-use guidance among the many sibling tools. It is minimally viable but has clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides only types and titles with 0% description coverage, so the description's Args block does essential work. It specifies that channel accepts 1 or 2 and gives the complete list of valid parameter strings. This resolves most of the semantic gap, though individual parameter meanings and units are not elaborated.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Measure a waveform parameter on the oscilloscope.' It clearly distinguishes this measurement operation from the many setup-oriented osc_* siblings, and the enumerated parameter list makes the tool's scope unambiguous. It is not a tautology and gives an agent a clear action to invoke.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use osc_measure versus alternatives such as dmm_measure, nor any exclusions or prerequisites. The description does not mention that the oscilloscope must be acquiring, the channel must be enabled, or how this measurement relates to other osc_* tools. Usage is only implied by the verb 'measure'.
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?
No annotations are provided, so the description carries full responsibility for behavioral disclosure. It states the action but does not disclose side effects, prerequisites, whether the current acquisition is cleared, whether the scope must be stopped, or how the setting interacts with timebase and acquire mode.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is tight: one action sentence plus a single arg line with examples. There is no filler, repetition, or unnecessary detail, and the key purpose is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter setter, the description is minimally adequate: it identifies the action, the target resource, and example values. However, with no annotations and no full value grammar, it leaves gaps around valid values beyond the examples and any operational consequences, so it is complete only in the most basic sense.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides only a bare string property with no description (0% coverage). The description compensates by labeling the parameter as 'Memory size' and giving concrete examples of valid notation such as '7K', '70K', '700K', '7M', and '14M', which substantially helps the agent format the value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'Set the acquisition memory depth on the oscilloscope.' This clearly identifies what the tool does and distinguishes it from sibling setter tools like osc_set_timebase, osc_set_acquire_mode, and osc_set_channel_scale.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The intended use is implied by 'memory depth' and the tool name, but the description gives no explicit when-to-use guidance or alternatives. Among many osc_set_* siblings, the agent must infer this is for acquisition memory only and is not told how this interacts with related settings like timebase or acquire mode.
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?
No annotations are present, so the description must disclose behavioral traits. It only says 'Set...' and documents arguments; it does not mention side effects on measurement scaling, validation of attenuation values, persistence, or error behavior. This is a mutating operation with no safety annotation to compensate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded: a one-sentence summary followed by concise Arg docs. No word is wasted and the most important detail, the operation, appears first.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given 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 covers the core operation and all parameters. However, missing usage guidance and behavioral side effects leave an agent with some uncertainty about validation and consequences, making it adequate but not complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description compensates by explaining channel is 1 or 2 and giving example attenuation factors. This adds meaning beyond the bare integer/number types, though it does not define the full set of accepted values.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'Set the probe attenuation factor on an oscilloscope channel.' This clearly identifies the operation and distinguishes it from sibling channel-configuration tools like osc_set_channel_scale or osc_set_channel_offset.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The operation is self-explaining, but the description does not state when to prefer it over alternatives or any prerequisites. It implies usage by naming the exact setting to change, yet no explicit routing or exclusion criteria 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?
No annotations are provided, so the description must carry the full behavioral burden. It states the action but does not disclose whether an existing preset gets overwritten, whether settings are persisted, or whether any state is affected beyond the preset.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely compact: one clear sentence followed by a single parameter definition. It is front-loaded with the core action and contains no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a simple one-parameter tool, and the description plus schema cover the essential call correctly, especially since an output schema exists. The only notable gap is the absence of overwrite/persistence semantics, which keeps it from being fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides only 'preset' as an integer with no description. The description closes this gap by explicitly specifying 'Preset number (1–5)', giving the agent the valid range needed to call the tool correctly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Save') with a clear resource ('current settings') and target ('a preset on the power supply'), so the operation is unmistakable. The name also distinguishes it from siblings like psu_recall by the direction of the operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance about when to use this tool instead of alternatives such as psu_recall. It does not state prerequisites, when saving is appropriate, or what distinguishes it from related preset operations.
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?
No annotations are provided, so the description carries the full burden. It states the core action but does not disclose side effects, prerequisites, whether burst must be active, or what happens if the instrument is in an incompatible 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short, direct, and front-loaded with the purpose. The parameter documentation is compact and adds necessary information without padding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter control operation, the description covers the essential scope and channel range. With an output schema present, return-value details are not required. It is adequate but could mention preconditions or interaction with other modulation modes.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaningful detail beyond the schema by specifying that channel must be 1 or 2. The schema only says 'integer', so this range constraint is valuable.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource: 'Disable burst mode on a waveform generator channel.' This clearly distinguishes the tool from siblings like arb_set_burst and arb_disable_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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The intended use is implied by the action itself: call this when burst mode needs to be turned off. However, the description does not explicitly state when to prefer this over related tools such as arb_disable_modulation or arb_disable_sweep.
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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only says the tool enables a frequency sweep and lists parameters; it does not disclose side effects, whether existing modulation/burst modes are overridden, permissions required, or what happens on the device after invocation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is minimal and well-structured: one concise purpose sentence followed by a compact parameter list. Every sentence earns its place and there is no redundant or filler content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The parameter list is complete and an output schema exists, so return-value documentation is not required. However, the description lacks important operational context such as interactions with modulation, burst, or output-state settings, which matters for a device-control tool with no annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description compensates by explaining all four parameters clearly: channel range (1 or 2), start and stop frequencies in Hz, and sweep time in seconds. This adds meaningful unit and constraint information beyond the bare schema types and titles.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action—"Enable frequency sweep on the waveform generator"—with a clear verb and resource. It implicitly distinguishes itself from sibling tools like arb_set_frequency (fixed frequency) and arb_disable_sweep (disabling 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The intended use is implied by the action verb and the sibling tool arb_disable_sweep, but the description does not explicitly state when to choose this tool over alternatives or mention exclusions. It provides no direct usage guidance beyond the operation itself.
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 no annotations, the description carries the burden. It clearly states the mutation: it changes the waveform type on a channel, and enumerates valid values. However, it does not mention side effects, whether this disables modulation/sweep, error behavior, or confirmations, 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short and front-loaded with the core action, followed by two clearly formatted argument explanations. Every sentence contributes necessary information and there is no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter setter with an output schema available, the description is largely complete enough to invoke the tool correctly. It lacks usage routing and some behavioral context, but the core target and allowed inputs are fully specified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. It does: channel is explained as 1 or 2, and waveform is given a concrete allowed list: SINE, SQUARE, RAMP, PULSE, NOISE, ARB, or DC. This makes the parameters actionable despite the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource: 'Set the basic waveform type on the waveform generator.' It clearly separates this from sibling setters like arb_set_frequency, arb_set_amplitude, and arb_set_output, even without naming them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does 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 such as arb_set_am, arb_set_sweep, or arb_set_burst. An agent must infer from the name that this sets the main waveform rather than modulation or sweep behavior.
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 core behavior: returning four summary statistics. However, with no annotations present, it does not state whether the statistics are computed live, whether statistics must be previously enabled, or what happens if no statistics are available.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that front-loads the operation and the result data. No filler or redundant text is present.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple zero-parameter query the description is mostly sufficient, especially with an output schema available to document the return shape. The main gap is the unstated requirement that statistics need to be enabled, but the sibling tool set makes this inferable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the schema is trivially complete. Per the rubric, a zero-parameter tool earns a baseline of 4; the description does not need to add parameter meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Query'), a specific resource ('statistics from the multimeter'), and enumerates the returned values (average, min, max, stddev). It clearly distinguishes this tool from the other DMM actions such as dmm_read, dmm_fetch, and dmm_measure.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool versus alternatives, and no mention of prerequisites such as statistics being enabled. Sibling names like dmm_enable_statistics imply a precondition, but the description itself does not communicate it.
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?
No annotations are provided, so the description carries the burden. It does indicate this is a non-mutating query via the word 'Query' and constrains the channel to 1, 2, or 3. However, it provides little else, such as error behavior or confirmation that it returns the configured setpoint rather than a measured value.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single clear sentence followed by a minimal parameter explanation. Every part is useful, and the key action is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter getter with an output schema, the description is largely complete: it states the operation, the resource, and the valid channel range. It does not explicitly contrast with psu_measure_voltage, but given the simple tool shape, the remaining gap is minor.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description compensates for the sole parameter by explaining that channel is a channel number and explicitly listing valid values (1, 2, or 3). This gives the agent the key semantic information the schema lacks.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description says 'Query the set voltage on a power supply channel,' which names a specific verb, resource, and scope. This clearly distinguishes it from siblings like psu_measure_voltage (actual measurement), psu_get_current (current), and psu_set_voltage (write).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no explicit guidance about when to use this tool versus alternatives. It does not state that psu_measure_voltage should be used for actual measured voltage or that psu_set_voltage is the write counterpart. The usage context is only implied by the phrase 'set voltage.'
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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It discloses that the tool measures actual current, but does not mention whether the output must be enabled, whether it triggers a new measurement or returns the last reading, or what units are returned. This is a significant gap for a measurement 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: one sentence for purpose and one line for the parameter. It is front-loaded with the core action and wastes no words, making it easy for an agent to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that an output schema exists (so return format need not be described), the description covers the essential facts: what the tool measures and the only parameter's valid values. It lacks explicit usage context vs. alternatives, but the simplicity of the tool and the presence of an output schema keep this from being a major gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema only defines 'channel' as an integer with no description, while the tool description adds concrete valid values: 'Channel number (1, 2, or 3).' This compensates for the 0% schema description coverage and gives the agent the essential constraint needed to call the tool correctly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Measure') and resource ('actual output current on a power supply channel'), making the tool's operation clear. It also distinguishes itself from sibling tools like psu_set_current and psu_get_current by emphasizing 'actual' output, which implies a measured value rather than a setpoint.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by saying 'Measure the actual output current,' which suggests using this when a live measurement is needed rather than a setpoint query (psu_get_current). However, it does not explicitly state when to choose this over alternatives or mention any exclusions, so the guidance remains indirect.
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?
No annotations are provided, so the description carries the full behavioral burden. It only states the mutating operation without disclosing side effects, persistence, whether the change is applied immediately, or how invalid thresholds are handled.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded, with a one-sentence action statement followed by a minimal Args list. Every sentence earns its place by adding parameter semantics.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given 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 is mostly complete: it explains what the tool does and documents both arguments with useful specifics. The main gap is a valid current range, but the overall context is sufficient for an agent to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the Args section is essential and valuable: it clarifies channel as 1 or 2 and current as OCP threshold in amps. It does not specify current range or resolution, but the core meaning is well conveyed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('Set'), a precise resource ('over-current protection threshold'), and the scope ('power supply channel'). This clearly distinguishes it from sibling tools like psu_set_current and psu_set_ovp.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The operation itself implies when it should be used: when configuring the over-current protection threshold on a channel. However, it gives no explicit guidance about alternatives, preconditions (e.g., output state), 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must carry behavioral context; it states the main destructive outcome (factory defaults) but does not disclose side effects such as loss of current settings, saved states, or whether the device reboots. The core behavior is clear, but richer operational consequences are 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact: a clear one-line purpose statement followed by a single argument specification. It front-loads the core behavior and avoids unnecessary filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter destructive tool with an output schema available, the description supplies the valid device keys and the core operation. It may lack explicit side-effect warnings, but an agent has enough information to select the tool and populate the required argument correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema only declares a required string named 'device' with no description or enum. The description compensates by enumerating the exact allowed keys ('arb', 'dmm', 'osc', 'psu'), which is essential for correct invocation. It doesn't explain the meaning of each key, but the keys are self-explanatory given sibling tool prefixes.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('reset') with a clear object ('a device') and outcome ('to factory defaults'), making the tool's purpose immediately evident. It also distinguishes itself from the sibling set, where no other tool performs resets.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to invoke reset versus alternatives such as psu_save/psu_recall or individual configuration setters. The description implies the use case (reverting to factory defaults) but does not state exclusions or prerequisites.
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 no annotations, the description carries the behavioral disclosure burden. It communicates a read-only intention via 'Query', and specifies that the result is an on/off state, but it does not disclose edge-case behavior such as invalid channel handling or communication errors.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short, front-loaded sentences with no redundant wording. The core capability is stated first, followed by the parameter clarification, and every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter query tool with an output schema available, this description is complete enough to invoke correctly. It gives the purpose, the exact valid channel values, and the expected query outcome; return value details are already covered by the output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema only provides 'channel' as an integer with title 'Channel' and no description. The tool description adds the valuable constraint 'Channel number (1 or 2)', which directly compensates for the 0% schema description coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Query') and resource ('waveform generator channel output'), and clearly states the result being determined ('on or off'). This distinguishes it from setter tools like arb_set_output and from getters on other instrument types like psu_get_output.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given about when to use this tool versus alternatives. It does not mention paired setter tools such as arb_set_output, nor any conditions or prerequisites for checking output state.
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 no annotations, the description must carry the behavioral burden. It clearly conveys the effect (sets duty cycle) and scope (square/pulse), but it does not disclose side effects, validation behavior, valid duty range, or whether the generator output must be active. Basic behavior is clear, but additional behavioral context 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded, with a short Args block that directly supports the two schema parameters. There is no redundant or filler content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-argument setter with an output schema, the core purpose and both parameters are documented. However, practical context is incomplete: it does not mention selecting a square/pulse waveform before use, the valid duty range, or any channel-specific behavior, leaving an agent to infer these details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides only types and titles, so the Args section adds genuine value: channel is constrained to 1 or 2 and duty is described as a percentage. Both parameters are covered, exceeding the 0% schema description coverage, though a numeric duty range and invalid-value handling are not specified.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific action ('Set'), the target property ('duty cycle (%)'), and the applicable context ('square/pulse waveforms on the waveform generator'). This distinguishes it from sibling tools like arb_set_frequency or arb_set_amplitude without requiring the schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'for square/pulse waveforms' implicitly limits applicability, but the description does not state when to use this tool versus sibling arb_set_* tools, nor does it mention prerequisites such as selecting the waveform type first or enabling the output. Usage guidance is only implied, not 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?
With no annotations, the description carries the full burden of behavioral disclosure. It states the action and valid coupling values, but does not mention side effects, such as whether GND coupling disconnects the input, whether the channel must be enabled first, or whether applying a new coupling affects measurement 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two compact sentences plus a short argument list. The main verb phrase is front-loaded, and every line earns its place by providing the key usage constraints without unnecessary prose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter setter with an output schema, the description supplies all information needed to invoke the tool correctly: the target resource, the argument constraints, and valid values. It could be more complete by noting behavior or prerequisites, but the core invocation context is covered.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but the description fully compensates by explaining both arguments: channel must be 1 or 2, and coupling must be AC, DC, or GND. These constraints are not present in the input schema, so the description adds essential meaning beyond the structured fields.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Set the coupling mode of an oscilloscope channel.' This clearly distinguishes it from sibling oscilloscope commands like osc_set_channel_state or osc_set_channel_scale. The scope and target are 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives, such as when changing coupling is appropriate or how it relates to other oscilloscope setup commands. The usage context is only implied by the tool name and description, with no 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?
No annotations are present, so the description carries full responsibility for disclosing behavior. It reveals only that this is a mutating 'set' operation and gives no side effects, preconditions, valid ranges, or instrument-state implications beyond the bare 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short and front-loaded with the core purpose, followed by a compact argument list. Every sentence adds necessary information and there is no repetition of schema fields or extraneous text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter setter, this description is minimally viable: it states the operation, the channel valid values, and offset units. However, it omits offset value constraints, required instrument state, and any behavioral caveats, which leaves some practical usage gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description compensates by explaining both parameters: channel is 1 or 2, and offset is expressed in volts. This adds meaningful semantic value beyond the raw types in the schema, though it does not give limits or units for channel beyond enumeration.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the specific action ('Set') on a specific resource ('vertical offset of an oscilloscope channel'), which is immediately distinguishable from the many sibling oscilloscope tools. No ambiguity remains about what this 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description makes it clear that this tool is for changing a channel's vertical offset, and among the sibling tools only this one has that role. It does not explicitly name alternatives or exclusions, but the intended context is unambiguous for an 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?
With no annotations provided, the description carries the behavioral burden. It does disclose the central behavior—toggling whether a channel trace is enabled or disabled—and the meaning of the state parameter. However, it does not mention whether this affects acquisition, run/stop state, or other channel settings, leaving some behavioral context implicit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and efficient: one sentence states the operation, followed by a minimal two-item Args block. There is no filler, and the core purpose is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter boolean setter, the description provides enough to invoke it correctly: both parameter semantics and the intended effect are clear. An output schema exists, so return-value details are not required. It lacks sibling differentiation, but this is covered by the usage_guidelines dimension.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema only indicates types (integer, boolean) with no semantic explanation. The description fully compensates by defining channel as '1 or 2' and state as 'True to enable, False to disable', which is essential and sufficient given the 0% schema description coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific operation ('Enable or disable') on a specific resource ('a channel trace on the oscilloscope'). This clearly distinguishes it from sibling tools like osc_set_channel_scale, osc_set_channel_offset, and osc_set_channel_coupling, which configure other aspects of a channel.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives, no prerequisites are mentioned, and no sibling tools are referenced. The agent must infer the intended use case from the name and the brevity of the description.
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?
No annotations are provided, so the description must carry behavioral context. It clearly indicates this is a state-setting operation and identifies the affected setting, but it does not disclose side effects, prerequisites such as channel enablement, or error behavior. This is adequate but 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded: one clear action sentence followed by a single argument definition. There is no filler, repetition, or extraneous detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple single-parameter setter with an output schema available, the description covers the essential information: the action, the affected instrument, and the valid channel values. It omits minor contextual details like prerequisites, but nothing critical is missing for a straightforward call.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description fully compensates by explaining that 'channel' means 'Channel number (1 or 2).' This adds a meaningful constraint that the schema itself does not provide, making the single required parameter unambiguous.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Set'), a specific resource ('trigger source channel'), and the instrument ('oscilloscope'). This distinguishes it from siblings like dmm_set_trigger_source and other trigger-related oscilloscope tools such as osc_set_trigger_mode, osc_set_trigger_level, and osc_set_trigger_slope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance about when to use this tool versus alternatives, and no prerequisites or exclusions. It only names the action; it does not explain when an agent should choose this over related trigger 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?
With no annotations, the description carries the full behavioral burden. It states the operation ('measure actual output power') and the word 'actual' usefully implies a live reading rather than a setpoint, but it does not disclose whether the channel must be enabled, whether this is non-destructive, or any timing/error behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short lines with the purpose front-loaded and an Args section for the parameter. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter measurement tool with an output schema available, the description covers the essential purpose and parameter range. It could be more complete with explicit usage guidance or preconditions, but nothing critical is missing for this low-complexity tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% and the schema only says 'Channel' as an integer. The description compensates fully by defining the single parameter as 'Channel number (1, 2, or 3)', adding the valid values the schema omits.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Measure') and a specific resource ('actual output power on a power supply channel'), which clearly distinguishes it from siblings like psu_measure_voltage and psu_measure_current.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to choose this tool over psu_measure_voltage/psu_measure_current or psu_get_*, and no mention of prerequisites such as the output being enabled. Usage context is only implicit in the verb and resource.
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 no annotations, the description must disclose behavior itself. 'Query' implies a read-only operation, and 'current' implies it returns the instrument's present state, but it does not clarify how auto-range mode affects the result or whether any measurement action is triggered.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single focused sentence with no filler. It front-loads the action and the object, making it immediately scannable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple zero-parameter getter with an output schema, the description covers the core action well. A small gap remains around auto-range behavior and relationship to related DMM tools, but it is not a critical omission.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has no parameters and the schema coverage is 100%, so there is no parameter-specific information the description needs to add. For a zero-parameter tool, the baseline score of 4 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Query') and a specific resource ('current measurement range on the multimeter'). This clearly distinguishes the tool from sibling setters like dmm_set_range and dmm_set_auto_range, as well as from dmm_get_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/5
Does 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 alternatives. The intended use is implied by the name and wording, but there is no contrast with related DMM operations such as dmm_set_range, dmm_set_auto_range, or dmm_read.
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 no annotations, the description alone must disclose behavioral traits. It states that this is a read operation, but does not say whether reading the queue clears/consumes the error, what happens when the queue is empty, or whether repeated calls return the same error. This is a meaningful gap for an instrumentation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is minimal and front-loaded: the core behavior appears in the first sentence, followed by a short parameter note. Every sentence earns its place and there is no redundant content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple and an output schema exists, so return-value documentation is not required. However, the description omits important queue behavior such as whether reading is destructive and what happens with no errors. This leaves a clear gap for an agent automating device interaction.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% and the only parameter has no enum. The description fully compensates by explicitly listing the valid device keys: 'arb', 'dmm', 'osc', 'psu'. This is exactly the information an agent needs to call the tool correctly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific action ('Read the latest error') and resource ('device error queue'). It is distinguishable from all sibling tools, none of which target error-queue reading.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context for use: it reads the error queue, and the device-key enumeration tells the agent which instruments apply. There are no competing sibling tools for reading errors, so explicit when-not-to-use guidance is not necessary.
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 no annotations, the description must carry behavioral transparency. 'Query' strongly implies a non-mutating read operation, which is useful, but the description does not disclose any further behavioral details such as error conditions or whether it reflects live instrument 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct, front-loaded sentence with no filler. Every word contributes to identifying the operation and resource.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter getter with an output schema available, the description is nearly complete. It does not elaborate on the exact meaning of 'timebase setting' or return behavior, but those are largely covered by the output schema and 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/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so parameter semantics are not a burden on the description. A baseline of 4 is appropriate because no parameter information is needed beyond the empty schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Query') and the target resource ('current timebase setting on the oscilloscope'). It is instantly distinguishable from siblings like osc_set_timebase because it is explicitly a getter for the current value.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The wording implies this is the tool to use when the current timebase setting is needed, and the 'current' qualifier contrasts with the setting counterpart. However, it does not explicitly state when to prefer this tool 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the side effect of setting trigger mode to AUTO, but it does not state whether the acquisition is continuous, whether the call blocks until a trigger, or how this interacts with an already-running acquisition.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The entire description is one focused sentence with zero filler. It front-loads the action and uses a parenthetical to convey the key side effect without adding length.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter command, the description covers the core effect and its side effect, and the output schema handles return-value expectations. It falls short of full completeness only because it does not place the command in relation to osc_single or osc_stop, but that gap is mostly covered by purpose clarity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes no parameters, so there is nothing to document beyond the schema. Per the baseline for zero-parameter tools, a 4 is appropriate; the description cannot add parameter meaning that does not exist.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Start acquisition') and resource ('oscilloscope'), and clarifies the behavioral scope with the parenthetical 'set trigger mode to AUTO'. This distinguishes it from siblings like osc_stop, osc_single, and osc_set_trigger_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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The parenthetical ('set trigger mode to AUTO') implies this is for AUTO-triggered continuous acquisition, but no explicit when-to-use or alternative guidance is provided. An agent must infer the distinction from the sibling names rather than from explicit routing instructions.
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?
No annotations are provided, so the description carries full responsibility for behavioral disclosure. It states this is a set operation but does not mention side effects, instrument prerequisites, valid scale ranges, or whether the setting persists. A mutation tool with no annotation coverage needs more 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded, with one clear sentence followed by a minimal argument definition. Every element earns its place and no redundant wording is present.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple single-parameter setter with an output schema, the description provides the essential invocation details: target resource, action, and parameter units. It is slightly incomplete only in lacking range or side-effect details, which are less critical for this low-complexity tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema only declares 'scale' as a number with 0% description coverage. The tool description compensates by defining 'scale' as 'Time per division in seconds,' adding units and physical meaning that are absent from the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource: 'Set the horizontal timebase (s/div) on the oscilloscope.' It clearly identifies what the tool does and distinguishes it from the sibling getter osc_get_timebase by the setter action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description makes the use case clear: change the oscilloscope's horizontal timebase. It does not explicitly name alternatives or exclusions, but the setter nature and the sibling osc_get_timebase make the intended usage obvious.
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?
No annotations are provided, so the description carries the full burden. 'Measure' implies a read-only action, but the description does not disclose whether this triggers a fresh measurement, blocks until a reading is available, or returns units. It is not misleading, but adds only minimal 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one short, front-loaded sentence followed by a minimal parameter list. Every word earns its place and there is no redundant boilerplate.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With a single required parameter, an output schema available, and a clear simple operation, the description is nearly complete. It could be improved by explicitly routing to psu_get_voltage for configured/set values, but for its complexity level the key information is present.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 0%, but the description explicitly defines the channel parameter as a channel number and restricts it to 1, 2, or 3. This adds meaningful constraints beyond the bare integer type in the schema, though it could have added unit or range details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource: it measures the actual output voltage on a power supply channel. The word 'actual' helps distinguish this from psu_get_voltage and sibling measurement tools like psu_measure_current, making the tool's purpose clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for measuring a live/actual voltage value rather than reading a configured voltage, but it does not explicitly say when to prefer this over psu_get_voltage or any other sibling. Guidance is left to inference.
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?
No annotations are provided, so the description carries the behavioral disclosure burden. It discloses the core mutation and adds useful constraints (channel 1-3, current in amps), but it does not mention side effects, prerequisites, immediacy, or persistence of the setting.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief, front-loaded with the core purpose, and includes only the necessary parameter details. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter setter with an output schema, the description covers the essential call details: what to set, which channel, and in what unit. It does not mention current limits or output-state prerequisites, but these are not needed for basic invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, but the description compensates by documenting both parameters: channel valid values (1, 2, or 3) and current unit (amps). It lacks current range or resolution details, but provides enough to construct a valid call.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action and resource: 'Set the output current limit on a power supply channel.' This clearly distinguishes it from sibling tools like psu_set_voltage, psu_get_current, and psu_set_ocp.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The intended usage is implied by the description: call this when you need to set a channel's current limit. However, it does not explicitly mention when not to use it or how it differs from related tools such as psu_set_ocp or psu_set_voltage.
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 no annotations provided, the description carries the full burden. It clearly discloses the enable/disable side effect and the True/False semantics, but it does not mention prerequisites, error behavior, or whether the change persists after a reset.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded with the core purpose, followed by a minimal, focused argument list. Every sentence earns its place and there is no redundant or vague wording.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter setter with an output schema available, the essential calling information is present. The only minor gap is the absence of context about device prerequisites or error conditions, but these are not critical for this basic toggling operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description fully compensates by explaining both parameters: channel is constrained to 1 or 2, and state maps True to enable and False to disable. This adds significant meaning beyond the schema's bare type declarations.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action—'Enable or disable the output of a waveform generator channel'—with a clear verb and resource. This distinguishes it from siblings like arb_get_output, which reads state, and other arb_set_* tools that modify waveform parameters.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The action is clear, but the description provides no explicit guidance on when to prefer this tool over alternatives, such as arb_get_output for querying the current state. Usage is implied rather than stated with exclusions or conditions.
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 no annotations, the description carries the full transparency burden. It clearly states the action and valid values, but it does not disclose side effects, prerequisites (such as whether the output must be disabled), or behavior after setting a non-standard load. The straightforward nature of a setter limits the impact of this 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded: one clear action sentence, then a compact argument list. Every sentence earns its place; there is no redundant or vague text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given 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 is largely complete: both parameters are well defined and an output schema handles return details. It lacks minor contextual notes about instrument state or exact numeric limits, but these are less critical for this operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description fully compensates: channel is defined as 1 or 2, and load is defined as 'HZ' or a numeric string in ohms with an example. This adds the exact meaning and format that the schema omits.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Set') and a specific resource ('output load impedance on the waveform generator'), which cleanly distinguishes it from sibling tools like arb_set_frequency or arb_set_amplitude. It also provides validates the allowed values for load, reinforcing the purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool through its explicit purpose, but it does not offer any explicit guidance, preconditions, or comparisons to alternative sibling tools. For example, it doesn't mention when to use this vs. other ar b set tools or whether any output state constraints apply.
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?
No annotations are provided, so the description carries the burden. The word 'Query' signals a read-only operation, which is the key behavioral trait. It does not disclose return shape, error behavior, or state assumptions, but the presence of an output schema mitigates some of that burden.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence with no filler. The verb and object are front-loaded, making it immediately scannable and useful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter getter with an output schema, the description is complete enough for an agent to call it correctly. No additional prerequisites, side effects, or return-value details are necessary at this level of complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the schema is trivially complete. Per the baseline for zero-parameter tools, this scores 4; the description adds context by naming exactly what is being queried.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Query') and a precise resource ('the current measurement function on the multimeter'). It clearly distinguishes this from sibling tools like dmm_set_function and dmm_get_range without needing to open the schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use when the agent needs to read the DMM's currently selected measurement function, which is a clear enough context. However, it does not explicitly contrast with alternatives or mention when not to use it; the guidance 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries full behavioral burden. 'Query' weakly implies a read-only operation, but the description does not explicitly state that no state is changed, how the query is performed, or what happens on error. For a simple query tool this is adequate but 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two lines with no filler; the action and the parameter constraint are front-loaded. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter query tool with an output schema, the description covers the essential semantics and valid input values. It omits explicit behavioral notes and usage conditions, but the cost is low given the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema coverage, the description's 'Device key – one of...' line adds the complete set of valid values, which the schema's bare string field does not provide. This is essential and fully disambiguates the parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb ('Query'), a concrete resource ('identification string of a device'), and the scope via allowed device keys. This clearly distinguishes it from siblings that set/get measurements, waveforms, or power-supply parameters.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the obvious use case—obtaining a device's identification string—but gives no explicit 'use when' or 'use instead' guidance. No alternatives or exclusions are mentioned, so the agent must infer 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?
No annotations are provided, so the description carries the full behavioral disclosure burden. It discloses that the tool sets a configuration value and is tied to average acquisition mode, and it documents the power-of-2 constraint. However, it does not state what happens if the instrument is not in average mode or if count is not a valid power of 2.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two tight blocks: a one-sentence purpose plus a one-line parameter explanation. There is no filler and the key facts are front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with one parameter and an output schema, so the missing return explanation is acceptable. The description covers purpose and parameter constraints, but it omits how to ensure the precondition (entering average acquisition mode) and what happens on invalid input, which an agent might need for fully reliable invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does 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 does: 'count: Number of averages (power of 2, e.g. 4, 16, 64, 256)' adds real meaning beyond the bare integer type and gives concrete examples. It stops short of a fuller range or minimum/maximum, but it is sufficient for typical use.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb+resource construction: 'Set the number of averages when in average acquisition mode.' This clearly states both what the tool does and the operating-mode context, and it is distinct from the many sibling osc_* tools because no other tool targets average count.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'when in average acquisition mode' gives a clear contextual condition for using this tool. It does not explicitly name alternatives or say when not to use it, but the mode qualifier is sufficient for an agent to understand it is only relevant to average-mode acquisition.
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 no annotations provided, the description carries the full burden. The verb 'Query' implies a read-only, non-destructive operation, but the description does not explicitly confirm side-effect-free behavior, unit handling, or error/return characteristics beyond what an output schema may provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact, front-loaded with the main purpose, and the argument documentation is minimal. Every part earns its place, and there is no extraneous repetition of schema information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter getter, the description is complete: it defines what is queried, the channel parameter range, and the operation's intent. The presence of an output schema covers return-value details that the description does not need to restate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema only declares 'channel' as an integer with no range or defaults, and schema description coverage is 0%. The description compensates fully by stating the allowed values: 1, 2, or 3. This is exactly the semantic information an agent needs.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Query') and a specific resource ('set current limit on a power supply channel'). This clearly distinguishes it from related siblings like psu_measure_current (measured current) and psu_set_current (setting the 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The described purpose is clear enough to imply when to use it, but there is no explicit guidance about when not to use it or how it differs from psu_measure_current. The phrase 'set current limit' provides context, but 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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It explicitly discloses the absence of a side-effect (no new trigger), which is the most important behavioral trait for an agent to know. It does not cover edge cases like behavior when no measurement exists, but for a zero-parameter fetch tool the core behavior is well conveyed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence that communicates both the action and the critical non-triggering behavior. Every word earns its place, with no redundant detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter tool with an output schema, the description provides all essential information needed to select and invoke it correctly. The distinguishing behavior is stated, and there are no hidden inputs or setup requirements to document.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the input schema is empty, so there is nothing for the description to document. The baseline of 4 applies because the description does not need to compensate for any undocumented parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Fetch'), a specific resource ('the last measurement from the multimeter'), and a key behavioral qualifier ('without triggering a new one'). This clearly distinguishes it from siblings like dmm_read and dmm_measure, which imply a fresh measurement.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'without triggering a new one' gives clear context: this tool is for retrieving an already-acquired measurement rather than initiating acquisition. It does not explicitly name alternative tools or state when not to use them, but the intended usage is clear from the contrast with triggering 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?
With no annotations, the description carries the burden and the word 'Query' plus returning on/off implies a read-only operation with no side effects. It does not discuss error behavior, but the presence of an output schema reduces the need to describe the 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact: one clear functional sentence followed by a single parameter explanation. No redundant wording or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter read-only query, the description fully covers the tool's purpose and the only input that matters. The output schema covers the return value, so nothing necessary for correct invocation is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema gives only 'integer' with no enum or description, while the description supplies the essential constraint that channel must be 1, 2, or 3. This directly prevents invalid calls.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states a specific verb ('Query') and resource ('power supply channel output'), and says exactly what is being determined: whether the output is on or off. This naturally distinguishes it from sibling psu_set_output, which changes the output state.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description makes clear the context: use this when you need to know the current on/off state of a power supply channel. It does not explicitly name alternatives or exclusions, but the query-vs-set distinction is evident from sibling tool names.
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:

[![SCPI_MCP MCP server](https://glama.ai/mcp/servers/colingimenez/SCPI_MCP/badges/card.svg)](https://glama.ai/mcp/servers/colingimenez/SCPI_MCP)

Score Badge

Copy to your README.md:

[![SCPI_MCP MCP server](https://glama.ai/mcp/servers/colingimenez/SCPI_MCP/badges/score.svg)](https://glama.ai/mcp/servers/colingimenez/SCPI_MCP)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

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/colingimenez/SCPI_MCP'

If you have feedback or need assistance with the MCP directory API, please join our Discord server