rigol-oscilloscope-mcp

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation4/5
Most tools target clearly distinct resources (channels, timebase, trigger, AFG, decode, waveform capture vs analysis). The descriptions actively disambiguate potential overlaps, e.g. capture_waveform vs analyze_waveform and measure vs capture_screenshot. The only mild ambiguity is get_trigger vs get_acquisition_state, which both report trigger status.
Naming Consistency4/5
The set follows a coherent verb_noun pattern: get_* for reads, configure_* for writes, capture_* for data/screen retrieval, and enable_afg/disable_afg for the generator output. Minor deviations exist: bare verbs (run, stop, single, autoset) and scope_identify which would fit better as get_identity, but these are consistent with their single-purpose nature.
Tool Count3/5
At 26 tools this is on the heavy side, but the surface covers a genuinely complex instrument: acquisition control, channel/timebase/trigger setup, measurements, waveform capture, screenshots, protocol decoding, and a function generator. Each tool has a distinct role, though the count exceeds the ideal 3-15 range and sits just past the 25-tool threshold.
Completeness4/5
The tool surface offers solid lifecycle coverage: connection management, full configuration (channel/timebase/trigger), acquisition control (run/stop/single/autoset), measurement plus raw data capture, screenshots, protocol decode, and complete AFG control including dangerous-operation confirmation flows. Minor gaps exist, such as no tool to enumerate decode buses directly (delegated to get_capabilities) and get_state not clearly covering decode settings, but these are workable.
Average 4.2/5 across 25 of 26 tools scored. Lowest: 3.2/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 68 commits in the last 12 weeks
- Last stable release on August 25, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.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

Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations present, the description carries the full burden and does well by disclosing several behaviors: returned data is in volts, data may be written to a CSV file with path in data_file, screen data may be decimated, and effective sample rate is the reciprocal of sample_interval_s. These are genuinely useful operational details.
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-loads the core behavior, with additional caveats placed after. It contains no filler, though the phrasing about decimation could be more directly connected to the input parameters.
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 reasonably complete for a capture operation: it covers unit conversion, CSV fallback, decimation, and sample rate. However, with no output schema and no parameter explanations, it leaves gaps around expected return shape and the meaning of channel and max_points.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain what channel or max_points mean or how they affect the capture. The mention of 'many points' vaguely relates to output handling, but it never ties that to max_points.
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 and resource: capturing waveform data and converting it to volts. This distinguishes it from a screenshot capture or decode, but it does not explicitly differentiate from closely related measurement tools like measure or analyze_waveform.
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 such as get_channel, measure, or analyze_waveform. It explains behavior but not the selection context or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavior. It implies a read-only query via 'return' but does not clarify whether a connection is required, what exactly constitutes 'state', or if there are any side effects. This is minimal disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no filler. It delivers the core purpose and parameter constraint up front.
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?
The tool has no output schema and the description does not describe the return format or the semantics of 'state'. It also omits any prerequisites (e.g., connection state). For a simple getter, an agent would still benefit from knowing what the response looks like, so the description is 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 input schema provides no description for the 'channel' parameter (0% coverage). The description compensates by specifying the allowed values ('CH1' to 'CH4'), which is essential and non-obvious from the schema alone.
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 ('return') and resource ('state of one channel'), and explicitly enumerates valid channel values ('CH1' to 'CH4'). This makes the tool's purpose unambiguous and distinguishes it from siblings like configure_channel and get_state.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/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. The description does not mention conditions, prerequisites, or exclusions, leaving the agent without context for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It usefully states that returned values use SI-suffixed keys and warns about quality validity. However, it does not disclose whether the operation is read-only, requires an active acquisition, or how errors are reported.
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-loads the core action, followed by the measurement enum and output format. All sentences contribute value, though the line breaks could be more structured for readability.
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?
Without output schema or annotations, the description must stand alone. It covers the key inputs and output format, but omits details such as error behavior, whether a waveform must already be acquired, and the exact shape of the returned object. Adequate but with 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 provides zero descriptions, so the description compensates by listing the allowed measurement strings and the output key naming convention. It adds real meaning beyond the bare schema, though the channel parameter is not further clarified.
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 action 'Measure the given channel' and enumerates the measurement types, making the primary function unambiguous. However, it does not explicitly distinguish this tool from siblings like analyze_waveform or capture_waveform, so it misses full 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?
There is no guidance on when to use this tool versus alternatives, no prerequisites, and no context about how it fits into a workflow. The list of measurements only hints at parameter selection, not 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?
With no annotations provided, the description carries the full burden for behavioral disclosure. It does disclose a non-obvious behavior: 'Omitted items are left unchanged' (partial update semantics) and requires at least one item to change. However, it does not mention side effects on acquisition, error handling, or whether the configuration persists across runs. The update semantics are useful but incomplete.
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 brief and to the point, using line breaks to separate parameter details. It avoids fluff and front-loads the primary purpose. The only minor issue is that level_v is not mentioned, but that is a completeness issue rather than a conciseness one. The structure is efficient.
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 mutation tool with no output schema, the description should explain expected return/confirmation, prerequisites (e.g., device connection), and all parameters. It omits level_v entirely and provides no information on the return value or any constraints that might cause errors. This leaves an agent without enough context to call it confidently in all cases.
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?
Schema has no descriptions (0% coverage), so the description must explain parameters. It does explain source, slope, and sweep_mode with their allowed values, which adds meaning. However, it completely omits level_v, leaving its units and range undocumented. It covers 3 of 4 parameters, providing partial but not complete 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 clearly states the tool's purpose: 'Configure the edge trigger.' It specifies the resource (edge trigger) and the verb (configure), and the allowed parameters make it distinct from sibling tools like get_trigger or configure_channel. This is a specific, unambiguous definition.
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 gives context that this is for configuring the edge trigger and lists allowed values for three parameters, which implicitly guides usage. However, it does not explicitly state when to use this tool instead of alternatives like get_trigger or configure_timebase, nor does it mention any prerequisites or exclusions. Some implied guidance but lacks explicit comparison.
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, and it delivers meaningful context: features can be restricted under generic profile confidence, and the options field returns null when unsupported by the model. These are non-obvious behaviors that an agent needs to interpret results correctly.
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 front-loaded with the core purpose, followed by two short sentences that each add non-obvious behavioral context. Every sentence earns its place; the only minor issue is that the third sentence is slightly wordy but still informative.
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 0-parameter tool with no output schema, the description covers the key surprises (conditional feature restriction, null options field) and hints at return content. However, it lacks explicit usage guidance and does not describe the return structure or fields an agent should expect, which matters more given there is no output schema to fill that 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?
There are zero parameters, so per the rubric the baseline is 4. The description correctly does not attempt to document parameters that do not exist.
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 first sentence states a specific verb ('Return') and resource ('features available on the connected device') with concrete examples (channel count, supported features). This makes the tool's intent clear and distinguishable from siblings like get_state or get_channel, though it does not explicitly name a sibling it is not.
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 when-to-use, when-not-to-use, or alternative routing guidance is given. The conditional statement about generic profile confidence describes behavior, not usage context. An agent is left to infer when this tool should be called relative to siblings like scope_identify or get_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 provided, the description must carry the full burden of behavioral disclosure. It does state that the action 'triggers once, then stops', which is a meaningful behavioral trait, but it does not explain side effects (e.g., what happens to previously acquired data, whether this changes the device state, or if it requires a configured trigger). For a simple control action, this is partial transparency but lacks full 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 a single, clear sentence with no redundant words. It front-loads the core action ('single-shot acquisition') and immediately states the stopping behavior. This is an ideal conciseness level for a no-parameter tool.
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 simple: no parameters, no output schema, and a clear one-sentence behavior. Given its elementary nature, the description is practically complete. However, it does not mention how it relates to sibling tools like 'run' or 'stop', nor does it clarify whether it requires a preconfigured trigger. These small omissions keep it from being a perfect 5.
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 input schema is empty and schema description coverage is trivially 100%. The baseline for no parameters is 4, and the description does not need to compensate for any parameter documentation gaps. It correctly implies there are no configurable options.
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 ('single-shot acquisition') with a clear behavioral qualifier ('triggers once, then stops'). It distinguishes itself from likely continuous acquisition tools like 'run' and from 'capture_waveform' by emphasizing the 'single' nature, though it does not explicitly name any sibling. This makes the purpose clear, but slightly generic because 'acquisition' is not defined further.
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 on when to use this tool versus alternatives such as 'run', 'stop', or 'capture_waveform'. The description does not mention conditions that would favor this tool over a continuous acquisition, nor any prerequisites or relationship to other tools. The agent is left to infer that 'single' is appropriate for one-shot measurements, but this is 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. 'Return' implies a read-only query, but the description does not explicitly confirm it is non-mutating or mention any side effects. For a simple getter this is minimal but acceptable.
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 sentence that front-loads the key information without any filler. Every word contributes.
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 getter with no params and no output schema, the description is adequate but lacks usage guidance and does not detail the exact return format or possible values (e.g., what the trigger status looks like).
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 no parameter explanation is needed. The schema is trivially covered, and the baseline for zero-parameter tools is 4.
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 ('Return'), the resource ('acquisition state'), and the content ('whether it is running, and the trigger status'). This makes it easy to distinguish from generic siblings like 'get_state' or 'get_trigger'.
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 on when to use this tool versus alternatives such as 'get_state' or 'get_trigger'. The description lacks any conditions, exclusions, or comparisons to siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. 'Return' implies a read-only operation, but the description does not explicitly state that it has no side effects, nor does it mention whether a connection or configuration is required. It adds the scope 'settings and status' but leaves the exact behavioral profile 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 a single sentence with the action verb first and the target resource immediately after. It contains no filler or redundant phrases, making it highly scannable and appropriately sized for a trivial getter.
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 read with no output schema, the description gives only a high-level indication of what is returned. It does not enumerate which trigger settings or what status fields are included, and with no annotations or output schema, an agent has limited information to anticipate the response shape. Additional detail about return contents would make it 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, so the input schema is empty and schema coverage is trivially 100%. The baseline for zero-parameter tools is 4, and the description correctly avoids inventing parameter details that do 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 uses the specific verb 'Return' and identifies the resource 'trigger' with the scope 'settings and status.' This clearly differentiates it from configure_trigger, which modifies trigger settings, and from broader getters like get_state, so an agent can select it without needing to open schemas.
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 usage guidance is provided. The description does not state when to use this tool versus configure_trigger or get_state, nor does it mention any prerequisites or exclusions. The agent must infer usage entirely from the tool name and the bare description.
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 behavioral disclosure. It adds 'continuous run,' which is useful, but it does not state whether acquisition continues until stopped, what happens if already running, whether it blocks, or what prerequisites exist. These are significant gaps for a control 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 a single short sentence that communicates the action and the key mode distinction without any filler. It is perfectly sized for a no-parameter 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 simple no-parameter trigger, the description is minimally viable, but it leaves clear gaps: no usage guidance versus single, no mention of stop as the counterpart, and no behavioral side effects. These omissions matter even in 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?
The tool has zero parameters and an empty schema, so the description has no parameter semantics to clarify. This matches the baseline for a no-parameter tool; there is nothing 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 verb ('Start') and resource ('waveform acquisition'), and the parenthetical 'continuous run' distinguishes it from one-shot acquisition tools like single. This is clear and unambiguous even without naming siblings.
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 'continuous run' implies use for continuous acquisition rather than single-shot, and the sibling list includes single and stop, but the description never explicitly says when to use run versus single or how to stop it. Usage context is implied, not stated.
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 of behavioral disclosure, and it does well: it explains partial updates, the minimum requirement, the possibility of value snapping, and advises trusting the read-back value. This gives the agent important expectations about device behavior beyond the basic input schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded, with each sentence earning its place: purpose, partial-update semantics, validation requirement, and a behavioral warning. No redundant or filler content exists.
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 gives essential behavioral context and implies a read-back value, but it does not explain prerequisites, return structure, or parameter semantics. For a simple two-parameter configure tool it is adequate, yet the lack of parameter explanation and explicit usage guidance leaves some gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description should compensate by explaining parameter meanings, but it does not mention position_s or scale_s_per_div explicitly. It refers to 'items' generically, leaving the agent to rely on the schema titles with no additional semantic guidance.
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 ('Configure') and the resource ('horizontal axis (timebase)'), making the tool's purpose immediately obvious. It is also distinct from sibling configure tools like configure_channel, configure_trigger, and configure_decode, so an agent can tell them apart.
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 is for changing timebase settings, but it does not explicitly state when to choose it over alternatives or provide exclusions. The 'Specify at least one item to change' line is useful, but there is no direct comparison to other configure 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 provided, the description carries the full burden of behavioral disclosure. It states the getter nature ('Return'), implying a non-destructive read, but does not mention prerequisites (e.g., connection state), side effects, or return format. For a simple getter, this is minimally adequate but lacks depth.
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, efficient sentence with no superfluous words. It is front-loaded with the action and resource, and every word earns its place. Perfect conciseness.
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 no-parameter, read-only getter with no output schema, the description provides sufficient context. It specifies the exact aspect of state being returned (horizontal timebase) and is complete for the low complexity. The only minor gap is lack of mention of return format, 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?
The tool has zero parameters, so the baseline for parameter semantics is 4 per the rules. The description correctly implies no parameters are needed by not mentioning any, and there is nothing to add beyond the schema which is already complete.
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 verb 'Return' and the resource 'the horizontal (timebase) state'. It distinguishes the tool from siblings like get_trigger and get_acquisition_state by specifying the timebase focus. The purpose is immediately 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 alternatives such as get_state or get_trigger. The description only gives the action and resource, leaving the agent to infer usage context. No exclusions or alternative routing are 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?
With no annotations, the description carries the full burden. It discloses the disconnected behavior (returns connected: false instead of error) and mentions the *IDN? query, adding useful context. However, it doesn't describe potential failure modes beyond disconnection or the format of the returned identity/profile.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the main function, then a note on disconnected behavior. 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 parameterless identification tool, the description covers what it returns and the key edge case (disconnected). Without an output schema, it doesn't need to detail return formatting. It is sufficient for an agent to call 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 zero parameters, the schema fully covers parameter semantics. The description need not add parameter detail, and the baseline for 0 params is 4.
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 verb (Return) and resource (connection state and device identity including *IDN? and profile). It distinguishes from siblings like get_state by combining connection state and identity, though it doesn't explicitly name alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear usage context: it is safe to call when disconnected, implying it can be used to check connection state. It does not explicitly list alternatives or exclusions, which are unnecessary for this simple tool.
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 behavioral disclosure burden. It explicitly states a key side effect: 'Any existing connection is replaced.' It also discloses default inference behavior for transport and port, which helps the agent predict what will happen beyond the parameter schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, front-loaded with the core purpose, and every sentence adds necessary guidance. It avoids redundant restatement of the tool name and keeps the important behavioral details in a small, scannable block.
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 connection tool with three optional parameters and no output schema, the description covers the essential context: what to pass, what to do when information is missing, default inference behavior, and the side effect of replacing an existing connection. It does not explain failure modes, but the invocation contract is sufficiently 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%, so the description must explain the parameters. It does: address is the user-provided connection target, transport is inferred from the address format, and port defaults to the profile value. It does not enumerate all transport options, but it compensates for the schema gap effectively.
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 a clear verb-plus-resource statement, 'Connect to the oscilloscope,' which identifies the tool's purpose and distinguishes it from sibling operations like disconnect, configure_trigger, or run. It does not explicitly contrast itself with alternatives, but the action is specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides concrete usage guidance: pass the address the user provided, ask the user rather than guessing, and rely on inference/defaults when values are omitted. It does not mention when to prefer sibling tools, but it gives clear operational context for calling connect correctly.
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 full burden. It discloses the behavioral effect ('freezes the waveform on screen') and the state change (stopping acquisition). However, it does not specify idempotency, side effects (e.g., whether the acquisition resumes later), or error conditions if already stopped. These omissions are minor for a simple 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?
A single sentence of ten words, front-loaded with the action and result, with no filler. It is appropriately sized for the tool's simplicity and makes efficient use of the description space.
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?
Given the tool's trivial nature (no parameters, no output schema, no annotations), the description provides the essential information: what it does and the observable effect. There is no additional context the agent would need to invoke it correctly, aside from the usage ambiguity already noted, which is covered under usage guidelines.
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 coverage is 100% (none to describe). The baseline for 0 params is 4; the description correctly avoids adding any parameter-related noise. No compensation is needed.
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 ('Stop') and resource ('waveform acquisition') and clarifies the result ('freezes the waveform on screen'). This clearly distinguishes it from siblings like 'run' and 'single'—an agent can infer its core function 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?
No explicit guidance on when to use this tool versus alternatives. The description implies stopping an ongoing acquisition, but it does not mention that 'single' also halts after one trigger, which could lead to confusion. There is no contrast with siblings or mention of prerequisites like needing an active run.
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 notes that closing an already disconnected connection is not an error, which is a useful non-obvious behavior. However, it does not disclose side effects like resource cleanup or impact on other operations, but for a simple disconnect the key behavior is covered.
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 states the core action and the one important edge case. No wasted words, and the key non-error condition is included. Ideal conciseness for a simple tool.
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 parameter-less, side-effect-simple action, the description is largely complete. It tells the agent what happens (closes the connection) and that being already disconnected is not an error. It does not describe what happens to ongoing operations or resources, but such detail may be unnecessary for this tool's simplicity. Given the lack of output schema and annotations, this is adequate.
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 trivially covers 100%. The description adds no parameter-specific meaning, but none is needed. A baseline of 4 is appropriate for parameter-less tools.
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 ('Close') and a specific resource ('the current connection'). It clearly distinguishes from the sibling 'connect' and other configuration tools. The 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?
No explicit guidance on when to use this tool versus alternatives. The context (a session lifecycle) implies it should be used after 'connect', but the description does not state this. There is no mention of alternatives or exclusions, leaving usage timing to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden and does so thoroughly: raw samples are never returned, analyses defaults to all, stats and fft contents are specified, and frequency accuracy is bounded by frequency_resolution_hz. These are precise behavioral constraints an agent can rely on.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded, with the core purpose in the first sentence and every subsequent sentence carrying operational detail. There is no repetition of schema fields or padded language.
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 tool with no annotations and no output schema, this description conveys the return contents and main parameter semantics well enough for typical use. It falls slightly short of complete because max_points is unexplained and the exact JSON shape of the returned summary is not described.
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 description adds strong meaning for analyses, including the allowed subset, the default, and the exact contents of each result type. However, schema description coverage is 0%, and channel and max_points receive no descriptive treatment; max_points in particular is left to inference.
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 object: Analyze a waveform on the host and return only the summary. It immediately separates itself from capture_waveform by stating that raw samples are never returned, so an agent can tell the two tools apart without inspecting schemas.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives an explicit when-not and alternative: when the raw data itself is needed, use capture_waveform instead. It also explains the default behavior of the analyses argument, so the agent knows omitting it yields all available analyses. This is direct routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations present, the description carries the full behavioral burden and does so excellently. It discloses partial-update semantics, value snapping with the need to trust the applied read-back value, and a safety-critical confirmation flow for impedance='50', including the fact that the first call does not execute and requires returning a confirm_token.
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 well-structured and front-loaded: the core purpose appears first, followed by parameter constraints, then the safety-critical confirmation flow. Every sentence earns its place, with no filler or repetition of schema details.
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 complex 9-parameter tool with no annotations and no output schema, the description is largely complete: it covers optionality, value snapping, and the dangerous impedance confirmation path. The main gap is that it never explicitly describes the response shape beyond mentioning confirm_token and the applied read-back value, but agents can still safely invoke the tool based on the available guidance.
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 tool description must compensate. It provides essential value constraints for channel ('CH1' to 'CH4'), coupling (DC / AC / GND), impedance ('1M' / '50'), and the confirm_token flow. Some parameters like offset_v, scale_v_per_div, and probe_ratio are left without explicit units or ranges, though their names provide reasonable hints.
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: 'Configure the vertical axis (a channel).' This clearly distinguishes the tool from siblings like configure_timebase and configure_trigger, and it immediately signals the scope of what can be changed.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly tells the agent when to use the tool: to change vertical-axis channel settings, and it explains that omitted items stay unchanged and at least one item must be specified. It does not explicitly name alternative tools for reading state or configuring other subsystems, so it stops short of full when-to-use-vs-alternatives guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden. It discloses a significant performance characteristic: 'a full read is about 39 queries and can take several seconds,' which is beyond what annotations would provide. It also clarifies the effect of the sections parameter on the response. However, it doesn't mention any potential side effects or return format, but for a read-only getter, the disclosure is solid.
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 three sentences long, front-loaded with the tool's purpose, followed by usage guidance and behavior. Every sentence adds value with no redundancy or filler. It is well-structured and easy to parse.
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 tool with one optional parameter and no output schema, the description is mostly complete. It explains the purpose, parameter semantics, and performance tradeoff. The only gap is a lack of explicit return value structure, but the tool is a simple getter and the description states it returns the requested sections, which is sufficient for 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 provides only a name and type for 'sections' with no description, so the description must compensate. It does: it explains that narrowing with sections is faster and that omitting returns every section, giving the parameter semantic meaning. It also lists the possible section names in parentheses (channels / timebase / trigger / acquisition), which helps an agent know what values to pass.
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 tool 'Get the main settings (channels / timebase / trigger / acquisition) in one call,' using a specific verb and resource. It distinguishes itself from sibling tools like get_channel, get_timebase, get_trigger, and get_acquisition_state by emphasizing it retrieves multiple sections in a single call.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly tells when to use the sections parameter: 'When you know what you need, narrowing with sections is much faster' and explains the tradeoff with a full read. It also states 'Omitting sections returns every section,' providing clear behavioral expectations. While it doesn't explicitly name alternatives, the guidance is sufficient for an agent to decide when to use this tool versus narrower getters.
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 full burden of behavioral disclosure. It discloses save location behavior, allowed-root restrictions, format options, and the return_image=false behavior. However, it does not specify the exact response structure (e.g., how the image is returned or what metadata fields are included) or default filename generation when path is a directory.
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 with the core purpose and then efficiently details each parameter in separate lines. Every sentence adds necessary information without redundancy or fluff.
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 tool with no output schema and no annotations, the description covers the essential invocation details, constraints, and alternative routing. The main gap is the exact return structure (metadata fields, image encoding), which an agent might need to process the result correctly. Still, it is largely complete for a straightforward screenshot capture 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 description coverage is 0%, so the description must explain all parameters. It does: path is described as a destination directory/file with resolution and allowed roots, format is enumerated as png/jpg/jpeg/bmp/webp, and return_image is explained as metadata-only when false. This fully compensates for the schema's lack of descriptions.
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 ('Capture'), resource ('the screen'), and outcome ('save it, and also return the image'), which is unambiguous. It also differentiates itself from the sibling tool measure by explicitly saying 'For numeric readings use measure, not this image.'
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly provides when-not-to-use guidance with 'For numeric readings use measure, not this image.' It also gives context for options like 'With return_image=false only the metadata is returned, without the image (saves tokens)', and explains path resolution against the invocation directory and allowed-root restrictions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden, and it excels: it discloses immediate effect, no confirmation flow, the safety rationale, that waveform settings persist, and that the return value contains channel state with output false. This goes well beyond the structured data.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core action, then adds rationale, usage timing, persistence behavior, and return value in a compact, well-organized way. Every sentence adds distinct value without redundancy.
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, side-effect-bearing tool with no output schema, the description is complete: it explains what happens, when to use it, why no confirmation is needed, what is preserved, and what the return value contains. Nothing essential for correct invocation is missing.
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?
Schema description coverage is 0%, so the description should compensate. It mentions 'the channel in state' and implies the channel parameter selects the AFG output to disable, but it never explicitly defines valid values or clarifies that the channel is the single parameter. The name/default make it inferable, but explicit guidance 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?
States a specific verb ('Turn off') and resource ('function generator output') with an immediate consequence ('no signal comes out any more'). This clearly differentiates it from enable_afg and other stop-type siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives explicit directives: 'Use it as soon as the measurement is done, and whenever the user asks for the signal to stop.' It also explains that no confirmation is needed by design, which tells the agent when direct invocation is safe, and references enable_afg as the counterpart for re-enabling.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and does so thoroughly. It discloses that the operation changes settings substantially, that previous settings are lost, that the first call does not execute, and that the changed settings are returned in state 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 three sentences with each sentence earning its place: purpose, destructive consequence, confirmation workflow, and resulting state. It is front-loaded with the core action and avoids unnecessary 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 single-parameter tool with no output schema and no annotations, the description covers the essential agent-facing facts: what changes, what is lost, the required confirmation flow, and what is returned. Nothing critical is missing for correct invocation.
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 only parameter, confirm_token, has no schema description, but the description fully explains its purpose and lifecycle: the first call returns a token, and the second call uses it to confirm execution. This adds meaning far beyond the raw schema, which only shows a nullable string with a null default.
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 identifies the action as 'Run Auto Setup (autoscale)' and states that it auto-adjusts vertical scale, timebase, and trigger. This distinguishes it from manual sibling tools like configure_timebase and configure_trigger by emphasizing that settings are changed together and previous settings are lost.
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 explicit procedural guidance: call once to get a confirm_token, ask the human user whether to proceed, then call again with that token. It does not explicitly compare against alternatives or state when not to use auto-setup, but the workflow is clear and actionable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description properly carries the behavioral burden: it explicitly states 'Reading never changes it' and 'This is read-only', and even discloses the cost of about 9 queries per channel. This gives an agent critical safety and performance information that would otherwise be unknown.
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 well-structured and front-loaded: purpose first, then behavior for each parameter variant, then the read-only note and cost. Every sentence adds necessary information, and the inline field list and JSON example are compact and clear.
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?
Given no output schema and no annotations, the description fully compensates: it explains the return format for both invocation modes, defines the meaning of 'output', and discloses side-effect-free behavior and performance cost. An agent has everything needed to call and interpret this tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description entirely compensates by explaining the optional 'channel' parameter's effect on the response format: flat fields for a single channel versus a 'channels' object keyed by channel number when omitted. This is far more meaningful than the bare schema, which only indicates the parameter may be an integer or null.
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 pair: 'Return the function generator settings', and pinpoints the distinguishing feature ('including whether the output is on'). It then details the exact shape of the returned data for both the channel-specific and all-channels cases, leaving no ambiguity about 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly explains when to include the channel parameter versus omit it, including the resulting return structure for each case. It does not explicitly name sibling tools or state when not to use this tool, but the context for using its own optional parameter is fully covered.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and exceeds it. It discloses the dangerous nature, the two-step confirmation flow (first call returns token, second call consumes it), token properties (channel-bound, single-use, expires), and the critical safety requirement to never self-confirm or drive live circuits. It also states the exact return shape ('settings with output true'). This is thorough behavioral disclosure well beyond the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Every sentence earns its place. The dangerous warning is front-loaded, followed by the two-step flow, then required safety checks, and finally return behavior and pointer to disable_afg. There is no redundant or vague wording; the structure guides the agent from danger identification to safe execution.
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?
Given the tool's complexity (dangerous action, two-step confirmation, no output schema, no annotations), the description is remarkably complete. It covers prerequisites, the exact calling sequence, safety constraints, token lifetime, and return value. It even tells the agent what to show the human user. Any missing edge cases (e.g., invalid token error) are minor given the strong procedural guidance.
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 thoroughly explains confirm_token: it comes from the first call, is required for the second, is single-use and expires. Channel is less explicit; the description references 'this channel' in the token binding but doesn't directly explain the parameter's valid values or meaning. Still, the description adds substantial semantic value for the more complex parameter, earning a 4 rather than a 3.
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?
Purpose is explicitly stated with a specific verb and resource: 'turn the function generator output on (a real signal starts coming out).' It distinguishes itself from disable_afg by explicitly naming it as the complementary off-switch, and from get_afg_state as the read-before-act tool. No ambiguity 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 Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description states it is 'the only tool that makes the instrument drive a signal,' which clearly establishes when to use it versus any sibling. It also prescribes a specific workflow: read get_afg_state first, show the user, ask about safety, then confirm. It names disable_afg as the tool for turning the output off, giving clear alternatives and conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations present, the description carries the full burden and does so thoroughly. It reveals that the output state is never touched, that out-of-range values are silently clamped with no error reported, that writing frequency while waveform is dc/noise is rejected, and that duty and symmetry settings are stored independently of the current waveform. This goes well beyond the input schema and gives an agent realistic expectations about side effects and failure modes.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Although the description is long, it is dense and every sentence earns its place given the zero coverage in the schema and nine parameters. The most important behavioral fact (never toggles output) is front-loaded right after the core purpose, and parameter details are grouped logically. No filler or repetition is present.
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?
The description is comprehensive for a complex configuration tool with no annotations and no output schema. It covers the output-state relationship, parameter meanings, units, valid values, clamping behavior, error rejection, and read-back guidance via 'compare applied (the read-back value) against requested.' An agent has enough context to invoke the tool correctly and interpret results.
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%, so the description must explain all parameters, and it does. It lists valid waveform strings, defines amplitude_vpp as peak-to-peak volts (not peak or RMS), specifies units and ranges for phase, duty, and symmetry, and explains the meaning of impedance. It also adds important caveats about parameter interactions, such as rejected frequency writes for dc/noise waveforms.
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 pair ('Configure the built-in function generator (AFG)') and immediately clarifies the scope with 'Omitted items are left unchanged.' This clearly distinguishes it from sibling tools like enable_afg, disable_afg, and get_afg_state, which are explicitly named in the description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit usage context: it does not turn output on/off, and it names the separate confirmation-gated tool enable_afg and disable_afg for that purpose. It also directs the user to get_afg_state for reading the current state, and distinguishes the AFG impedance setting from the oscilloscope input impedance in configure_channel. These are clear when-to-use and when-not-to-use guidelines.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden, and it does so well. It discloses that omitted items are left unchanged, that bus count is model-dependent, that unsupported protocol variants are rejected, and that the tool only affects display/analysis, not acquisition settings.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long but justified by the tool's complexity. It front-loads the core purpose and the 'omitted items are left unchanged' behavior, then uses clear per-protocol bullets and examples so the content is scannable and every section 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 complex configuration tool with no annotations and no output schema, this description is remarkably complete. It covers all parameters, protocol-specific variants, examples, model dependency, the required sequence for later decoding, and the separation from acquisition configuration. An agent has enough context to invoke it correctly.
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 thoroughly. It defines protocol and data_format values, source value ranges, all settings keys per protocol, and provides concrete examples for each protocol. It also clarifies enabled and event_table semantics in the workflow for get_decode_result.
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 'Configure a serial protocol decode bus,' which is a specific verb and resource that immediately identifies what the tool does. It also distinguishes itself from sibling configuration tools by listing protocol-specific details and noting that acquisition settings are separately configured via channels and trigger.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives clear when-to-use context: configuring decode buses, with bus count determined by get_capabilities. It explicitly routes related work elsewhere by saying 'acquisition settings are untouched, so configure the channels and trigger separately,' and tells the user to set event_table=true before reading results with get_decode_result.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and excels: it warns that no table is read if configuration is missing, that the table is only a snapshot if acquisition is running, that column names are variable, and that values are strings formatted according to data_format. It also discloses truncation semantics via max_events and event_count.
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 well-structured and dense, with the core purpose front-loaded, followed by prerequisites, then data-format caveats. Every sentence adds value, and no fluff or repetition exists.
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?
Despite having no output schema or annotations, the description fully equips an agent to call the tool correctly: it covers preconditions, variable column names, units, formatting, and truncation behavior. No critical gap remains.
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%, so the description must compensate. It does: 'bus' is explained as decode bus 1-4, and 'max_events' is described as returning only the first N events, with event_count always the total count before truncation.
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: 'Read the decoded event table of a decode bus (bus 1-4).' It clearly distinguishes this tool from siblings like configure_decode and stop, and the bus range adds precise scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states prerequisites: call configure_decode with enabled=true and event_table=true first, and stop acquisition before reading. It also explains the consequence of not following these steps, leaving no doubt about when and how to use the tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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:

[![rigol-oscilloscope-mcp MCP server](https://glama.ai/mcp/servers/zinntikumugai/rigol-oscilloscope-mcp/badges/card.svg)](https://glama.ai/mcp/servers/zinntikumugai/rigol-oscilloscope-mcp)

Score Badge

Copy to your README.md:

[![rigol-oscilloscope-mcp MCP server](https://glama.ai/mcp/servers/zinntikumugai/rigol-oscilloscope-mcp/badges/score.svg)](https://glama.ai/mcp/servers/zinntikumugai/rigol-oscilloscope-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/zinntikumugai/rigol-oscilloscope-mcp'

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