Skip to main content
Glama
kitour

RIGOL MHO98 MCP

by kitour
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

measure

Get numeric measurement values from a scope channel by specifying the item (e.g., FREQUENCY, VPP). Avoids image processing, returning precise data for stable analysis.

Instructions

Query a single-source built-in measurement on a channel. Preferred over screenshot for reading values — numeric results are cheaper and easier to analyse than an image. For stable readings: on DS1000Z, stop acquisition first. On DHO, keep acquisition running — the DHO measurement engine only populates item values from live acquisitions; some items (VMAX/VMIN/VTOP/FREQUENCY/…) return 9.9E37 if first queried on a stopped scope. channel: CHAN1–CHAN4. item: VMAX, VMIN, VPP, VTOP (pulse top flat level, histogram-derived — not the same as VMAX), VBASE (pulse base flat level — not the same as VMIN), VAMP (=VTOP−VBASE — not the same as VPP=VMAX−VMIN), VAVG, VRMS (RMS over screen window), PVRMS (RMS over one period), VUPPER/VMID/VLOWER (timing thresholds at 90%/50%/10% of VAMP by default), VARIANCE (statistical variance of voltage samples), FREQUENCY, PERIOD, PWIDTH, NWIDTH, PDUTY, NDUTY, RTIME, FTIME, OVERSHOOT, PRESHOOT, PSLEWRATE, NSLEWRATE (slew rate, V/s), TVMAX, TVMIN (time position at which VMAX/VMIN occurs), MAREA (waveform area, V·s over screen window), MPAREA (area per period, V·s), PPULSES, NPULSES, PEDGES, NEDGES. A return value of 9.9E37 is the scope's invalid/overflow sentinel — it means the measurement could not be computed (e.g. FREQUENCY returns 9.9E37 when the timebase is too narrow to show a complete cycle; widen scale and retry); such values come back annotated as invalid/overflow. If the channel's display is OFF it is auto-enabled first (noted in the result). For delay or phase between two channels use measure_between. Do not call concurrently with any other rigol tool.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
itemYesMeasurement item (e.g. FREQUENCY, VPP, VRMS)
channelYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A5/5.0
Behavior5/5

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

With no annotations, the description carries full behavioral burden and does so thoroughly: it documents the 9.9E37 invalid sentinel and its meaning, explains that display OFF is auto-enabled, describes model-dependent behavior, and warns against concurrent calls. This is exemplary transparency for a measurement 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 long but every segment earns its place: purpose is front-loaded, followed by operational caveats, a complete item enumeration, and sentinel semantics. The item list is dense but scannable, and no information is redundant 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?

Given no output schema and no annotations, the description fully equips an agent to call the tool correctly: it covers return values, invalid-value handling, channel/item choices, device-specific setup, side effects, concurrency, and alternatives. There are no obvious missing details for successful 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?

Schema coverage is only 50%, but the description fully compensates by enumerating every valid item and clarifying subtle semantics (e.g. VTOP is histogram-derived, VAMP = VTOP−VBASE, VUPPER/VMID/VLOWER are thresholds). It also lists the channel range CHAN1–CHAN4, adding meaning far beyond 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 opens with a specific verb and resource: 'Query a single-source built-in measurement on a channel.' It also distinguishes itself from the screenshot tool ('Preferred over screenshot for reading values') and from measure_between via 'single-source,' making sibling differentiation immediate and clear.

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 explicit when-to-use guidance (preferred over screenshot for numeric readings), model-specific prerequisites (stop acquisition on DS1000Z, keep running on DHO), a routing rule for two-channel measurements ('use measure_between'), and a concurrency prohibition. This leaves no ambiguity about when the tool should be called.

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

Deploy Server

Other Tools