This server provides programmatic control and data acquisition from Rigol DHO800/DHO900 oscilloscopes over LAN via the Model Context Protocol (MCP).
Identify & Status: Query device identity (*IDN?) and retrieve comprehensive status including trigger state, sample rate, memory depth, timebase, and per-channel settings.
Run Control: Start/stop acquisition, arm single-shot, autoset, clear waveforms, and force trigger.
Configure Channels: Enable/disable channels, set vertical scale, offset, coupling (AC/DC/GND), probe ratio, bandwidth limit, and invert.
Configure Timebase: Set horizontal scale (s/div) and offset.
Configure Trigger: Set edge trigger source, slope (positive/negative/either), level, and sweep mode.
Configure Acquisition: Set memory depth, acquisition type (Normal/Average/Peak/Ultra), and average count.
Measurements: Perform automatic measurements (VPP, VRMS, VAVG, frequency, period, rise/fall time, duty cycle, etc.) on any channel.
Waveform Capture: Retrieve scaled voltage/time data from screen (~1000 points) or deep memory (scope must be stopped), with summary statistics and optional decimated sample arrays.
Screenshot: Capture the scope's display as a PNG image.
Raw SCPI Commands: Send arbitrary SCPI commands as an escape hatch for any functionality not covered by dedicated tools (opt-in via RIGOL_ENABLE_SCPI_RAW=1).
Deployment: Runs locally via stdio or as a Docker container with HTTP or stdio transport, compatible with standard MCP clients.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@rigol-dho-mcp Identify the oscilloscope"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
An MCP (Model Context Protocol) server for controlling and reading Rigol DHO800/DHO900 series oscilloscopes over LAN, built on the SCPI command set from the official programming guide. It talks directly to the scope's raw SCPI socket on port 5555, so there's no VISA install to deal with.
Note: This server is currently pinned to
mcp<2.0.0. The official MCP Python SDK's v2.0 release renamesFastMCPtoMCPServerand moves it out ofmcp.server.fastmcp, which breaks this server's imports as written. The pin inpyproject.tomlkeeps deploys working untilserver.pyis migrated to the v2 API.
Tool | Purpose |
|
|
| Trigger state, sample rate, memory depth, timebase, per-channel settings |
| run / stop / single / autoset / clear / force_trigger |
| Enable, V/div, offset, coupling, probe ratio, BW limit, invert |
| Main timebase scale and offset |
| Edge trigger source, slope, level, sweep mode |
| Memory depth, acquisition type, averages |
| Automatic measurements (VPP, VRMS, FREQuency, RTIMe, etc.) |
| Scaled voltage/time data from screen or deep memory, with stats |
| PNG of the scope's display |
| Raw SCPI escape hatch for anything else in the guide |
| Set cursor mode (OFF/MANual/TRACk), type, source, and positions |
| Read cursor positions and delta/frequency readouts |
| Delay or phase between two channels (RRDelay, FFPHase, etc.) |
Related MCP server: rigol-mcp
Connect the scope to your LAN and grab its IP address under Utility > IO on the scope.
That's really it. The raw SCPI socket on port 5555 is open by default.
pip install .
RIGOL_HOST=192.168.1.100 rigol-dho-mcpThis starts the server on stdio, ready for any MCP client to spawn and talk to it directly.
rigol-dho-cli talks straight to the scope over the same SCPI client the MCP server uses — no MCP client required. Handy for checking a command works, or debugging the connection before wiring it up as a tool.
pip install .
# one-shot: run one or more commands and print the result, then exit
RIGOL_HOST=192.168.1.100 rigol-dho-cli "*IDN?" ":CHANnel1:SCALe?"
# interactive REPL: omit the commands
RIGOL_HOST=192.168.1.100 rigol-dho-cli
scpi> *IDN?
RIGOL TECHNOLOGIES,DHO814,...
scpi> :RUN
OK (system error queue: 0,"No error")
scpi> :DISPlay:DATA? PNG
binary response (34521 bytes) -> saved to capture_00001.png
scpi> quitIt reads the same RIGOL_HOST / RIGOL_PORT / RIGOL_TIMEOUT env vars as the server (or pass --host / --port / --timeout directly). Queries (commands ending in ?) print the response; writes are followed by a :SYSTem:ERRor? check so a typo shows up immediately. Binary responses (screenshots, waveform data) are saved to a file in the current directory instead of being dumped to the terminal.
docker build -t rigol-dho-mcp .
docker run -d --name rigol-dho-mcp \
-p 8000:8000 \
-e RIGOL_HOST=192.168.1.100 \
rigol-dho-mcpThis exposes the MCP endpoint at http://<docker-host>:8000/mcp (streamable HTTP).
Alternatively, you can use docker-compose.yml:
# Copy the example environment file and edit it with your scope's IP address:
cp .env.example .env
# Edit .env to set your scope's IP address under RIGOL_HOST
# Then start the service:
docker compose up -d
# View logs:
docker compose logs -f
# Stop the service:
docker compose downdocker run -i --rm \
-e RIGOL_HOST=192.168.1.100 \
-e MCP_TRANSPORT=stdio \
rigol-dho-mcpThe container needs to be able to reach the scope's IP. On Linux the default bridge network usually works fine; if your scope only sits on the host's LAN segment and bridge routing doesn't reach it, add
--network host. For docker-compose, you can uncomment thenetwork_mode: "host"line indocker-compose.yml.
This is a standard MCP server, so any client that speaks MCP over stdio or streamable HTTP can use it. The config shape is basically the same everywhere: point the client at the rigol-dho-mcp command (stdio) or the running HTTP endpoint, and pass RIGOL_HOST.
stdio:
{
"mcpServers": {
"rigol-dho800": {
"command": "rigol-dho-mcp",
"env": { "RIGOL_HOST": "192.168.1.100" }
}
}
}Streamable HTTP (pointing at the Dockerized server from above):
{
"mcpServers": {
"rigol-dho800": {
"url": "http://localhost:8000/mcp"
}
}
}If your client doesn't support remote MCP servers natively, use mcp-remote as a bridge instead:
{
"mcpServers": {
"rigol-dho800": {
"command": "npx",
"args": ["mcp-remote", "http://localhost:8000/mcp"]
}
}
}Check your client's docs for exactly where this config goes; the values themselves don't change.
When running with HTTP transport (Docker or MCP_TRANSPORT=streamable-http), the MCP server exposes an endpoint at http://<host>:8000/mcp.
⚠️ Important: This endpoint has no authentication mechanism. Anyone who can reach this port can control your oscilloscope and read waveform data/screenshots.
Because of that, compose.yml publishes the port on loopback only (MCP_BIND_ADDRESS=127.0.0.1) by default. The intended deployment is behind a reverse proxy that adds authentication.
To expose it on your LAN anyway, set MCP_BIND_ADDRESS=0.0.0.0 in .env — and be aware that this makes the scope controllable by anyone who can reach the port.
To put it behind Traefik, uncomment the labels block in compose.yml and drop the ports: block.
⚠️ Authentik/SSO note: this is a pure-API service. MCP clients can't complete an interactive browser login, so forward-auth SSO middleware (
authentik_domain@file) will break every client. Use a non-interactive credential — abasicauthor bearer-token middleware — instead.
CORS is not access control. MCP_ALLOWED_ORIGINS constrains browsers only; curl, a script, or any non-browser MCP client is unaffected by it regardless of how it's set.
The HTTP transport includes DNS rebinding protection by default (MCP_ENABLE_DNS_REBINDING_PROTECTION=1). This validates Origin and Host headers on incoming requests to prevent malicious websites from accessing your MCP server through a browser. It is a useful control, but it is not authentication — a direct client that sets an allowed Host header passes it trivially.
Both allowlists default to empty, which rejects everything:
Allowed Hosts: set MCP_ALLOWED_HOSTS to the exact host:port you connect to (e.g. localhost:8000, scope.home.lab:8000). With protection enabled and this unset, every request is rejected with 421 Misdirected Request — if the server appears to reject all traffic, this is why.
Allowed Origins: set MCP_ALLOWED_ORIGINS only if a browser-based client needs access (e.g. http://localhost:6274 for MCP Inspector).
The container healthcheck endpoint /health is intentionally exempt from these checks and reports HTTP liveness only — it doesn't probe the scope and returns no information about it.
⚠️ Warning: Setting
MCP_ENABLE_DNS_REBINDING_PROTECTION=0or usingMCP_ALLOWED_ORIGINS=*disables this protection entirely and should only be done on trusted, isolated networks for local testing.
Every tool parameter that gets interpolated into a SCPI command is an enumerated type or a bounded number, and the SCPI client rejects any command containing control characters or non-ASCII. This is what keeps RIGOL_ENABLE_SCPI_RAW=0 meaningful: SCPI is newline-delimited, so without both checks an embedded newline in a parameter would reach the scope as a second, arbitrary command.
If you add a tool, do not interpolate a free-form str into a command string — give the parameter a Literal type.
The scpi_command tool is opt-in via the RIGOL_ENABLE_SCPI_RAW=1 environment variable. When enabled, it accepts arbitrary SCPI commands from the MCP client.
⚠️ Warning: Arbitrary SCPI can leave the scope in any state or perform destructive actions (e.g.,
*RSTto reset the scope, changing critical settings). Ensure your MCP client has appropriate access controls and that you understand the risks before enabling this feature.
Variable | Default | Meaning |
| — (required) | Scope IP address or hostname |
|
| SCPI socket port |
|
| I/O timeout, seconds |
|
| Transport |
|
| HTTP bind address/port inside the container |
|
| Host interface compose publishes the port on. |
|
| Validate |
| — (empty) | Allowed |
| — (empty) | Allowed browser origins; also configures CORS |
|
| Container memory ceiling (deep-memory reads need ~2 GB) |
|
| Set to |
Deep-memory reads (get_waveform with mode="memory") need the scope in the STOP state, so call run_control("stop") first. Data comes back in chunks and gets decimated to max_points before returning.
Waveform samples are scaled to volts using the preamble: V = (raw − YORigin − YREFerence) × YINCrement.
A measurement value near 9.9e37 just means it's invalid for the current signal. get_measurement flags this for you.
scpi_command is opt-in (set RIGOL_ENABLE_SCPI_RAW=1). It checks :SYSTem:ERRor? after write-only commands, so a typo in raw SCPI shows up right away instead of failing silently.
The official MCP Python SDK's v2.0 release (stable as of late July 2026) replaces FastMCP with MCPServer and relocates it out of mcp.server.fastmcp. server.py still imports the old path (from mcp.server.fastmcp import FastMCP, Image), so an unpinned install pulls v2 and crashes on startup with ModuleNotFoundError: No module named 'mcp.server.fastmcp'. The mcp<2.0.0 pin in pyproject.toml avoids this for now. Migrating server.py to the v2 API is planned but not yet done.
Set acquisition memory depth, mode, and average count.
| Name | Required | Description | Default |
|---|---|---|---|
| acq_type | No | ||
| averages | No | Average count (power of 2, 2-65536); only for AVERages mode | |
| memory_depth | No | AUTO, 1k, 10k, 100k, 1M, 5M, 10M, 25M, or 50M |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It does not disclose side effects, whether changes are reversible, or any required instrument state. The description only states the action without behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence of 8 words, front-loaded with the key action. No redundant or superfluous information. Highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the basic action but lacks details on interaction with other settings, defaults, or return values. For a simple configure tool, it is minimally adequate but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 67%, and the description adds minimal value by paraphrasing parameter names. For acq_type (no schema description), it only says 'mode', missing the enum values. Overall, description does not significantly enhance schema understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool sets acquisition parameters (memory depth, mode, average count) with a specific verb and resource. It distinguishes from sibling configuration tools like configure_channel or configure_timebase, though it does not explicitly differentiate usage.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like configure_channel or configure_timebase. Lacks context for prerequisites or conditions under which this tool should be invoked.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Configure an analog channel. Only the parameters you pass are changed; the tool returns the channel's resulting settings.
| Name | Required | Description | Default |
|---|---|---|---|
| scale | No | Vertical scale in V/div | |
| invert | No | ||
| offset | No | Vertical offset in V | |
| channel | Yes | Channel number 1-4 | |
| enabled | No | ||
| coupling | No | ||
| probe_ratio | No | Probe attenuation, e.g. 1, 10, 100 | |
| bandwidth_limit | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses two key behaviors: only passed parameters are changed (partial update) and the tool returns the resulting settings. This is helpful but omits potential side effects or prerequisites.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no fluff. The first sentence states the purpose, the second adds crucial behavioral information. Efficient and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 8 parameters and no output schema, the description covers the partial update and return behavior but lacks details on the return structure and parameter interactions. Adequate but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 50% (low), and the description adds no extra meaning to individual parameters. It only states that parameters are passed but does not elaborate on any parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool configures an analog channel, distinguishes it from siblings like configure_acquisition or configure_timebase. It uses a specific verb and resource.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus other configure tools. The name and description imply it is for analog channels, but alternatives are not mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Set the main horizontal timebase scale and/or offset.
| Name | Required | Description | Default |
|---|---|---|---|
| scale | No | Main timebase in s/div, e.g. 0.0002 for 200 µs/div | |
| offset | No | Horizontal offset in seconds |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description does not disclose behavioral traits such as side effects, required permissions, or whether the change takes effect immediately. With no annotations provided, the description fails to inform about behavior beyond the basic action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence that conveys the core function without unnecessary words. It is appropriately short and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description lacks information about constraints, valid ranges, or the effect on other settings. Given the tool's role in configuring an oscilloscope, the description should provide more context for correct usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides descriptions for both parameters (scale and offset). The description repeats the parameter names but adds no additional semantic meaning. Baseline 3 given 100% schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (set) and the resource (main horizontal timebase scale and/or offset). It is specific and distinct from sibling tools like configure_channel or configure_acquisition.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. The description only states the action without context about usage scenarios or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Configure edge triggering (source, slope, level, sweep mode). Sets trigger mode to EDGE, then applies only the parameters given.
| Name | Required | Description | Default |
|---|---|---|---|
| level | No | Trigger level in volts | |
| slope | No | ||
| sweep | No | ||
| source | No | Trigger source: CHAN1-CHAN4, EXT, ACL (AC line), or D0-D15 (DHO900) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description must cover behavioral traits. It mentions the side effect of setting the trigger mode to EDGE, and that it's a partial update. However, it does not discuss error conditions, prerequisites, or whether changes are reversible.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description consists of two concise sentences. The purpose is front-loaded, and there is no redundant information. It could be slightly more specific about the parameters, but it remains efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 4 parameters and no annotations or output schema, the description provides the core functionality but lacks information about return values, error handling, or state dependencies. It is adequate but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 50% (level and source have descriptions). The description merely lists the parameters without adding semantic detail beyond the schema, so it does not significantly compensate for the missing schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly specifies the verb 'configure' and the resource 'edge triggering', listing the parameters. It distinguishes from sibling configuration tools by focusing on edge triggering specifically.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description states that the tool sets the trigger mode to EDGE and only applies the given parameters, providing clear context for usage. However, it does not explicitly mention when not to use it or list alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Perform an automatic measurement on a channel and return its value.
Common items: VPP (peak-to-peak), VAVG, VRMS, VMAX, VMIN, FREQuency, PERiod, RTIMe (rise time), FTIMe (fall time), PDUTy (duty cycle). Values are in SI units (V, s, Hz). A value near 9.9e37 means the measurement is invalid for the current signal.
| Name | Required | Description | Default |
|---|---|---|---|
| item | Yes | Measurement item, one of: VMAX, VMIN, VPP, VTOP, VBASe, VAMP, VAVG, VRMS, OVERshoot, PREShoot, MARea, MPARea, PERiod, FREQuency, RTIMe, FTIMe, PWIDth, NWIDth, PDUTy, NDUTy, TVMAX, TVMIN, PSLewrate, NSLewrate, VUPPer, VMID, VLOWer, VARiance, PVRMS, PPULses, NPULses, PEDGes, NEDGes | |
| channel | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description transparently explains the tool reads a measurement on a channel and returns a value, including a sentinel for invalid results. It does not discuss side effects or permissions, but the behavior is straightforward.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences plus a bullet list; front-loaded with the primary action. Every sentence adds value, no fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description covers the return value format and invalid indicator. It also lists common items, but could better explain the channel range and default.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds context beyond the schema by listing common items and explaining SI units and invalid value, compensating for the 50% schema coverage. However, it does not elaborate on the channel parameter beyond implying its use.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it performs an automatic measurement on a channel and returns a value, listing common measurement items. This distinguishes it from sibling tools like get_waveform or get_status which return raw data or status.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides examples of common items and explains interpretation of invalid values, but does not explicitly compare to alternative tools or state when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Capture the scope's current display as a PNG image.
Useful for visually inspecting waveforms, menus, and measurement readouts exactly as shown on the instrument's screen.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. Description mentions output format (PNG) but does not disclose idempotency, side effects, or prerequisites (e.g., display must be active).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise, front-loaded sentences. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no parameters and no output schema, the description fully covers the tool's purpose and usage context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist, so description needs no additional param info. Schema coverage is 100%.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clear verb 'capture' and specific resource 'scope's current display as a PNG image'. Distinguishes from sibling tools like get_waveform which captures raw data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states usefulness for visual inspection of waveforms, menus, and readouts. Lacks explicit exclusions or alternatives but context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get an overview of the scope's current state: trigger status, sample rate, memory depth, timebase, and per-channel settings.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description must convey behavior. 'Get an overview' implies a non-destructive read operation, which is apparent. However, it doesn't explicitly state there are no side effects or prerequisites, leaving some ambiguity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is a single, concise sentence that effectively communicates the tool's purpose without unnecessary words. It is well-structured and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given zero parameters and no output schema, the description provides a good list of returned information (trigger status, sample rate, etc.). It could be more complete by hinting at the output format, but for a simple status tool it is sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist, and schema coverage is 100%. The description adds value by explaining what the tool returns (list of status fields), which is useful beyond the empty schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it returns an overview of the scope's current state, listing specific elements like trigger status and per-channel settings. This makes the purpose clear, though it doesn't explicitly differentiate from sibling tools like get_measurement.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool vs alternatives. The description implies it's for getting current settings, but does not mention when not to use it or refer to sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Capture waveform data from a channel, scaled to volts and seconds.
Returns summary statistics (vmin/vmax/vpp/vavg/vrms) plus decimated time/voltage arrays. In 'memory' mode the scope must be stopped first (use run_control 'stop'); the full memory depth is read and decimated.
| Name | Required | Description | Default |
|---|---|---|---|
| mode | No | 'screen' reads the ~1000 displayed points; 'memory' reads deep memory (scope must be STOPped) | screen |
| channel | No | ||
| max_points | No | Max points returned (data is decimated to fit) | |
| include_data | No | If false, return only statistics, no sample arrays |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses scaling, return values (statistics and decimated arrays), decimation behavior, and the memory mode requirement. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences: first states purpose, second details returns and modes. No unnecessary words, front-loaded with the core action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, but description adequately covers return types (summary stats, time/voltage arrays) and decimation. Provides prerequisite for memory mode. Sufficient for agent to use correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 75% (3 of 4 parameters described). The description reinforces mode meanings but adds minimal new info beyond the schema's parameter descriptions. Baseline 3 with slight value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Capture waveform data from a channel, scaled to volts and seconds', using a specific verb and resource. It distinguishes from siblings like configure_* and get_measurement by focusing on raw waveform capture.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly describes two modes ('screen' and 'memory') and provides a prerequisite for memory mode: 'the scope must be stopped first (use run_control 'stop')'. This guides correct usage but does not explicitly say when to avoid the tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Query the instrument identity (*IDN?) to verify the connection.
Returns manufacturer, model, serial number, and firmware version. Use this first to confirm the scope is reachable.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but the description fully discloses that it is a read-only query returning specific identity fields. No side effects or permissions mentioned, but sufficient for a simple probe tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short, front-loaded sentences with no extraneous text. Efficiently conveys purpose and usage.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Zero parameters and an output schema exist, so description doesn't need to detail return values. Completely adequate given the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters; description correctly implies no input is needed. Schema coverage is 100%, so no additional parameter info required.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it queries the instrument identity via *IDN? and lists the returned fields (manufacturer, model, serial number, firmware version). Distinct from sibling tools like configure_acquisition or get_measurement.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly recommends using this tool first to confirm the scope is reachable, providing clear when-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Control acquisition state.
run: start continuous acquisition (:RUN)
stop: stop acquisition (:STOP) — required before reading deep memory
single: arm a single-shot acquisition (:SINGle)
autoset: auto-configure vertical/horizontal/trigger for the applied signal
clear: clear all waveforms on screen (:CLEar)
force_trigger: force a trigger event (:TFORce)
| Name | Required | Description | Default |
|---|---|---|---|
| action | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description explains what each action does (e.g., start, stop, arm, auto-configure). It mentions a key behavioral constraint for 'stop'. With no annotations provided, the description covers basic behavior but lacks depth on side effects or error conditions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, using bullet points for each action. Every sentence adds value, and the purpose is front-loaded. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter tool with an output schema, the description covers all actions and provides necessary context (e.g., stop requirement). It is complete given the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Despite 0% schema description coverage, the description fully explains each enum value of the 'action' parameter, adding critical meaning beyond the bare enum list. This compensates entirely for the missing schema documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Control acquisition state' and lists six specific actions, each with a brief explanation. This distinguishes it from sibling tools like 'configure_acquisition' or 'get_waveform'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides explicit context for 'stop' (required before reading deep memory), indicating when it's necessary. However, it does not explicitly exclude other use cases or mention alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Send an arbitrary SCPI command from the DHO800/900 programming guide.
Commands ending in '?' are treated as queries and their response is returned; others are write-only. Use for anything not covered by the dedicated tools (cursors, math, decoding, mask tests, DVM, etc.).
| Name | Required | Description | Default |
|---|---|---|---|
| command | Yes | Raw SCPI command, e.g. ':CHANnel1:SCALe 0.1' or ':ACQuire:SRATe?' |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses that commands ending in '?' are treated as queries with response returned, others are write-only. However, it could mention potential error handling or restrictions, but is mostly adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with purpose. No wasted words. Efficient and clear.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Has output schema, so return values are covered. Description is complete for a generic SCPI command tool, given sibling tools cover specific functions. Tells exactly what it does and when to use it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a good description for the 'command' parameter. Description adds context about query vs write-only but doesn't add much beyond schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it sends arbitrary SCPI commands from a specific programming guide. It distinguishes from dedicated tools by specifying 'use for anything not covered by the dedicated tools'. The description also clarifies query vs write-only behavior.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says when to use this tool (for anything not covered by dedicated tools) and describes the behavior for queries vs write-only. It references a specific programming guide, providing clear guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v0.1.0configure_acquisitionconfigure_channelconfigure_timebaseconfigure_trigger_edgeget_measurementget_screenshotget_statusget_waveformidentifyrun_controlscpi_commandEach tool targets a distinct aspect of the oscilloscope: configuration (acquisition, channel, timebase, trigger), measurement, screenshot, status, waveform capture, identification, run control, and generic SCPI. No overlap.
Tools use snake_case with verb_noun pattern (configure_*, get_*), but 'identify' is a lone verb and 'run_control' combines multiple actions. Minor inconsistency, but overall clear.
11 tools is well-scoped for an oscilloscope MCP, covering essential operations without being excessive.
Covers core functionality: configuration, measurement, waveform, screenshot, status, run control. Missing dedicated cursor/math tools but covered by the generic scpi_command, so minor gap.
Documentation for the Spektralwerk spectrometer SCPI API as a streamable HTTP MCP Server
QuLab MCP remote server (Streamable HTTP) for computational science and lab tools.
MCP server for network documentation, generated by doc2mcp.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/mattjax16/rigol-dho-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
