Click on "Deploy 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., "@scpi-mcp Capture the signal on channel 1"
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.
LabLink gives agents a SCPI wire; scpi-mcp gives agents oscilloscope expertise.
scpi-mcp is a Model Context Protocol server
that lets an agent operate an oscilloscope — not just push SCPI strings at one.
It exposes goal-level tools (capture this signal, measure that, characterize a
channel) backed by a clean, instrument-agnostic interface. All vendor SCPI lives
in the underlying instrument library; the MCP layer stays a thin, uniform wrapper
with no raw-SCPI escape hatch.
.-"""-.
/ .===. \ Skippi 🧚♂️
\/ 6 6 \/ the artistic scope gremlin
( \___/ ) "every waveform is a portrait of the magic pixies"
___ooo___ooo___Skippi is the mascot — the artistic gremlin who lives in the scope and paints pictures of the magic pixies (the ones who carry every electron down the probe). When you see a clean trace, that's Skippi's latest masterpiece.
First instrument: Rigol DS1054Z (unlocked to DS1104Z base) — 4 analog
channels, 100 MHz. No :SOURce (function generator) or :LA (logic analyzer)
support. Reachable over USB or LAN (TCPIP::<ip>::INSTR).
Related MCP server: rigol-mcp
transport/ — owns discovery. Enumerates USB, falls back to best-effort
LAN auto-discovery, then to an IP prompt; resolves a single VISA resource
string and hands it to the instrument layer. Discovery never leaks upward.
instruments/ — vendor-specific backends behind one abstract base.py
interface. rigol_ds1000z.py is a thin wrapper over the (complete) library;
mock.py implements the same interface with zero hardware. Adding an
instrument is one new file here and zero changes to tools/.
tools/ — instrument-agnostic MCP tools that call only base.py.
config.py — permission tiers (read_only / read_config / full),
enforced at the tool layer. The server refuses; the model never decides.
Live hardware, active bench use. The Rigol DS1054Z is connected and scpi-mcp is driving real measurements — see Skippi in the Wild for captures. The mock backend remains available for development and CI.
uv sync
uv run pytest # all green against the mock, zero hardware
uv run scpi-mcp # start the MCP server (mock backend by default)Real captures from the bench, analyzed live via scpi-mcp.
The setup: A 24 V relay coil (with freewheel diode installed) powered from a bench supply. Probed at the moment of power-off to observe inductive kickback. CH1 watches the supply rail; CH2 sits across the freewheel diode.
Prompts used:
Grab the scope screen.
What are the min and max voltages on each channel?
Is that spike on CH2 actually 60 V, or is the scale messing with me?scpi-mcp called capture_screen and measure_snapshot, then explained the
visual illusion: CH2 is set to 1 V/div, so its 5.36 V kickback spike fills
5+ of the 8 vertical divisions and looks enormous. CH1 is at 8 V/div, so
the 24 V rail only occupies ~3 divisions despite being far larger in absolute
terms. No 60 V spike — the freewheel diode clamped it cleanly to
V_supply + V_f ≈ 24.7 V, right where it should be.
500 ms/div (5 s full sweep). CH1 yellow, 8 V/div: 24 V supply decaying from 26.9 V → 2.24 V. CH2 cyan, 1 V/div: freewheel diode kickback, max 5.36 V, min −2.08 V.
The setup: The same 24 V relay coil, but with the freewheel diode removed — a bare inductor. Powered from a bench supply (100 nF across the rail to tame switch-mode ripple). Two 10x probes straddle the disconnect on the high side: CH1 on the supply side, CH2 on the coil side. Power is cut by pulling the + lead, and a single-shot trigger catches the unclamped kickback.
Prompts used:
Prime the scope for a single-shot on CH2 falling — I'll pull the + lead.
We didn't clear the clipping — reset V/div on CH2 and re-arm for another one-shot.
Got it — grab the screencap and give me the true peak.scpi-mcp armed a single-shot falling-edge trigger on CH2, watched the trigger status, and grabbed the screen plus both channel waveforms the instant it fired. This time the scale fought back the other way: the kick kept overflowing the window — it railed at ±130 V, then again at −304 V — so scpi-mcp stepped CH2 coarser to 100 V/div until the whole transient fit. With no freewheel diode to absorb it, the collapsing field threw a −436 V spike with a +240 V overshoot — a ~676 Vpp ring, roughly 18x the 24 V rail — then bled off exponentially back toward the rail over ~1 ms. Compare the clamped case above, where the diode held the same coil to ≈24.7 V.
200 µs/div. CH1 yellow, 20 V/div: supply side holds ~24 V with a small coupled ring at the break. CH2 cyan, 100 V/div: bare-coil kickback — peak −436 V, +240 V overshoot (~676 Vpp), then exponential bleed-back. No freewheel diode; contrast the ≈24.7 V clamped result above.
MIT
Set acquisition type and/or memory depth. Disruptive — needs confirm=True.
Deeper memory captures more points at a given time base; averaging/peak modes trade update rate for noise rejection or glitch capture.
| Name | Required | Description | Default |
|---|---|---|---|
| confirm | No | Safety gate for this disruptive action. Must be True to run — the server refuses the call when False. | |
| acq_type | No | Acquisition mode: 'NORMal', 'AVERages', 'PEAK', or 'HRESolution'. None leaves it unchanged. | |
| memory_depth | No | Record length in sample points (e.g. 12000, 120000, 1200000). None leaves it unchanged. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but description fully bears the transparency burden. It discloses disruptive nature, need for confirmation, and explains behavioral trade-offs of memory depth and acquisition modes beyond what the schema provides.
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?
Extremely concise: two sentences that front-load the purpose and critical behavior. Every sentence adds value without redundancy.
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 the presence of an output schema (not shown) and full schema coverage, the description is complete enough. It covers parameter behavior and the critical confirmation requirement. Minor gap: no mention of prerequisites like oscilloscope state, but acceptable.
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%, so baseline is 3. Description adds operational meaning by explaining the effect of deeper memory (more points) and the trade-offs of averaging/peak modes (update rate vs noise rejection).
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 type and/or memory depth, with specific verbs and resource. It distinguishes from sibling tools like acq_run, acq_single, or set_timebase by focusing on acquisition configuration parameters.
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 notes the tool is disruptive and requires confirm=True, providing clear context for when to use the confirm parameter. Does not explicitly list when not to use or alternatives, but the purpose is clear enough for the agent to differentiate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Force a trigger now, ignoring the trigger condition. Needs confirm=True.
| Name | Required | Description | Default |
|---|---|---|---|
| confirm | No | Safety gate for this disruptive action. Must be True to run — the server refuses the call when False. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description effectively communicates the tool's disruptive nature: it ignores trigger conditions and requires a confirmation flag. The parameter description reinforces this as a 'safety gate' and 'disruptive action.' Behavior is well disclosed.
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 short, front-loaded sentences with no filler. Each word adds value, making it highly concise and 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?
Given the tool has only one parameter and an output schema exists, the description covers the essential behavioral context (forcing trigger, needing confirmation). It is complete for the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides a detailed description of the 'confirm' parameter as a safety gate. The tool description adds 'Needs confirm=True' but does not go beyond the schema. With 100% schema coverage, 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?
The description clearly states the tool forces a trigger immediately, ignoring normal conditions. The verb 'Force' and resource 'trigger' are specific. It distinguishes from siblings like acq_run (normal execution) or acq_single (single trigger setup).
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 indicates the tool requires 'confirm=True' to execute, implying it's for bypassing conditions. However, it does not explicitly state when not to use or suggest alternatives, leaving usage context somewhat implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Start continuous (free-running) acquisition. Disruptive — needs confirm=True.
| Name | Required | Description | Default |
|---|---|---|---|
| confirm | No | Safety gate for this disruptive action. Must be True to run — the server refuses the call when False. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It clearly labels the action as 'disruptive' and requires confirmation, providing key behavioral information. However, it does not elaborate on the nature of disruption (e.g., stopping other acquisitions).
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 the core action, and no extraneous words. Every sentence earns its place.
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 the tool's simplicity (one parameter, output schema present), the description covers purpose and behavior adequately. It lacks explicit guidance on how continuous acquisition interacts with other acquisition modes, but the sibling list provides 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?
Schema coverage is 100% with the confirm parameter fully described as a safety gate. The description's 'needs confirm=True' adds no new meaning, so the score is at baseline for high 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?
Description clearly states 'Start continuous (free-running) acquisition,' specifying the verb 'start' and the resource 'acquisition' with the qualifier 'continuous.' This distinguishes it from siblings like acq_single (single-shot acquisition) and acq_stop.
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?
States 'Disruptive — needs confirm=True,' which provides a critical condition for use. While it doesn't explicitly mention when not to use or list alternatives, the sibling tool names imply other acquisition modes, and the guideline is succinct.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Arm a single-shot acquisition: capture one trigger then stop. Needs confirm=True.
Pair with set_trigger to catch a one-off transient (e.g. a power-on spike).
| Name | Required | Description | Default |
|---|---|---|---|
| confirm | No | Safety gate for this disruptive action. Must be True to run — the server refuses the call when False. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must convey behavioral traits. It notes the need for confirmation (implying disruptiveness) and describes the single-shot nature. However, it does not disclose potential side effects like resetting previous configurations or behavior if already armed.
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 sentences: the first states the core purpose, the second provides usage guidance. No redundant or irrelevant information. Well front-loaded and 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 primary use case and prerequisite. An output schema exists, so return values are handled. It could be more complete by mentioning error conditions or additional context, but it is sufficient for a simple tool.
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 only parameter, confirm, is fully described in the schema (safety gate, must be True). The description merely restates 'Needs confirm=True', adding no new meaning. With 100% schema coverage, baseline score of 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?
The description clearly states the tool's function: 'Arm a single-shot acquisition: capture one trigger then stop.' It distinguishes from siblings like acq_run and acq_stop by specifying single-shot behavior and pairing with set_trigger for one-off transients.
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 mentions prerequisite 'Needs confirm=True' and recommends pairing with set_trigger for transient capture. While it doesn't explicitly exclude alternative scenarios, the use case is well-defined and the guidance is practical.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Stop acquisition, freezing the current trace. Disruptive — needs confirm=True.
| Name | Required | Description | Default |
|---|---|---|---|
| confirm | No | Safety gate for this disruptive action. Must be True to run — the server refuses the call when False. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It labels the tool as 'Disruptive' and requires 'confirm=True', effectively communicating the behavioral impact. However, it omits details on reversibility or side effects, which would be useful but not critical for a stop 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?
The description is two sentences long with no redundant words. It front-loads the primary action ('Stop acquisition') and quickly adds the critical usage note. Every sentence earns its place.
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 the tool's simplicity (one parameter, output schema present), the description is adequate. It covers the core function and the essential behavioral cue. Missing details like the return value are covered by the output schema, so no major gaps.
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 100% (the confirm parameter is well-documented in the schema). The description merely reiterates 'needs confirm=True', adding minimal extra meaning beyond the schema, so a baseline score of 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?
The description clearly states the verb 'Stop' and the resource 'acquisition', and adds 'freezing the current trace' for precision. It distinguishes from siblings like acq_run and acq_configure by mentioning disruption, making the purpose unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly mandates 'confirm=True' as a prerequisite, indicating the critical usage condition. However, it does not contrast with alternatives like acq_run or when not to use this tool, leaving some ambiguity for an agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Report the connected instrument's detected capabilities.
Returns channel count/ids, bandwidth, source & logic support, max memory
depth, and installed options. Takes no arguments; requires a prior
self_config. Use it to learn what the scope can do before driving it.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description effectively discloses behavioral traits: it is a read-only report, requires a prerequisite, and explains its purpose. No contradictions or hidden effects mentioned.
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 sentences: first sentence lists purpose and outputs, second provides usage context. Every sentence adds value, no redundancy.
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 output schema exists, description does not need to detail return values. It covers prerequisite, purpose, and output scope, fully sufficient for this simple tool.
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 in schema, so description correctly states 'Takes no arguments.' Baseline 4 applies as there is nothing more needed.
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 the tool reports detected capabilities of the connected instrument, listing specific outputs like channel count/ids, bandwidth, etc. Distinguishes itself from sibling tools which focus on acquisition, configuration, or 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 notes it requires a prior self_config and should be used to learn capabilities before driving the instrument. Provides clear context but could be more explicit about 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 multiple channels on the same time base, time-aligned.
The instrument shares one time base across channels, so a sequence of reads is already time-aligned. (Real hardware reads them back-to-back; the mock is instantaneous.) Use this to compare two signals sample-for-sample.
| Name | Required | Description | Default |
|---|---|---|---|
| deep | No | If True, read deep memory for each channel; if False (default), read the on-screen trace. | |
| channels | Yes | Analog channels to capture together, e.g. [1, 2]. Read on the shared time base so the traces are time-aligned. | |
| include_samples | No | If True, include the full time/volts sample arrays. Default False returns only a summary (point count, sample rate, start/end time) to avoid flooding the context. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It explains the hardware behavior (back-to-back reads) and mock behavior, providing good transparency about the tool's operation. Could mention potential limitations like channel availability.
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 moderately concise, with two short paragraphs. It front-loads the purpose and includes necessary details. Minor redundancy in first paragraph could be trimmed.
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 the presence of an output schema (mentioned in context signals), the description does not need to detail return values. It adequately covers key aspects like time alignment and output summary. Missing context like prerequisites might be acceptable.
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 covers 100% of parameters. Description adds value by explaining why channels are time-aligned, what deep memory means, and why include_samples affects output size. This goes beyond just repeating 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 states it captures multiple channels on the same time base for time-aligned comparison. This distinguishes it from siblings like capture_memory, which likely captures single channels or in a non-aligned way.
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 explains when to use (comparing two signals sample-for-sample) and provides context about shared time base. However, it does not explicitly state when not to use or mention alternatives like capture_memory.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Capture the deep-memory waveform for one channel (full sample-rate record).
| Name | Required | Description | Default |
|---|---|---|---|
| points | No | Number of deep-memory sample points to read back. None reads the full acquisition record. | |
| channel | Yes | Analog channel to read, 1-based (1–4). | |
| include_samples | No | If True, include the full time/volts sample arrays. Default False returns only a summary (point count, sample rate, start/end time) to avoid flooding the context. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description bears full responsibility for disclosing behavioral traits. It only states the high-level action and lacks details about side effects, permissions, data volume implications, or what happens to existing recordings.
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 a single concise sentence with no extraneous words. It efficiently conveys the core purpose without redundancy.
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?
Despite the tool having a complex output and being used for data capture, the description omits any mention of return values or output schema. It does not explain that the output includes either full sample arrays or a summary, leaving the agent to infer from the schema alone.
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 input schema provides descriptions for all three parameters (100% coverage). The description adds no additional parameter-level context beyond the schema, so a baseline score of 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?
The description clearly states the verb 'capture' and the resource 'deep-memory waveform for one channel' with the detail 'full sample-rate record'. It distinguishes itself from sibling tools like capture_screen or capture_aligned by specifying deep-memory and per-channel operation.
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 provides no guidance on when to use this tool versus alternatives such as capture_aligned or capture_screen. There is no mention of prerequisites, context, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Capture the on-screen waveform for one channel (~1200 points).
| Name | Required | Description | Default |
|---|---|---|---|
| channel | Yes | Analog channel to read, 1-based (1–4). | |
| include_samples | No | If True, include the full time/volts sample arrays. Default False returns only a summary (point count, sample rate, start/end time) to avoid flooding the context. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. The description mentions 'one channel (~1200 points)', giving a sense of data volume and that it's a snapshot. However, it does not disclose side effects, whether it's read-only, or any other behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence that is front-loaded with the core purpose. No redundant or extraneous information.
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 the low complexity (2 parameters, high schema coverage, output schema present), the description is adequate. It conveys the essential behavior and data scope, though it could briefly mention the include_samples parameter's effect.
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 100%, so parameters are already documented. The description adds context about ~1200 points but does not elaborate on parameter meaning beyond what the schema provides. 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?
The description clearly states the verb 'Capture', the resource 'on-screen waveform', and specifies it's for one channel with a sample count hint (~1200 points). It implicitly distinguishes from sibling tools like capture_memory or capture_aligned, which likely capture different types of waveforms.
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 alternatives like capture_aligned or capture_memory. The description implies it's for capturing the current on-screen display, but lacks when-to-use or when-not-to-use context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Characterize the signal on channel — the FLAGSHIP goal-level tool.
Runs the probe → vertical fit → horizontal fit → trigger hunt → characterize
loop, settling and re-verifying after each adjustment (bounded by
:data:`MAX_SETTLE_ITERATIONS`). Returns the discovered signal parameters, a
full measurement snapshot, and a confidence flag. When ``export_path`` is
given, the deep-memory capture is rendered to a PNG there.
| Name | Required | Description | Default |
|---|---|---|---|
| channel | Yes | Analog channel to characterize, 1-based (1–4). | |
| export_path | No | Optional filesystem path to render the fitted deep-memory capture to a PNG. None skips the export. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description details the iterative algorithm, settling, and re-verification, which goes beyond the minimal. No annotations exist, so the description carries the full burden. It does not explicitly mention side effects or permissions, but the process seems non-destructive. The behavioral description is fairly thorough.
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 front-loaded with the core purpose and then explains the process and outputs. It is concise but includes all necessary details. A minor improvement could be slightly more brevity, but it is well-structured.
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 the tool's complexity (multi-step loop with settle iterations) and the presence of an output schema covering return values, the description provides a good overview. It covers the algorithm, what it returns, and the optional export. It is reasonably complete, though it could elaborate on the confidence flag or iteration bound.
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 mentions both parameters ('channel' and 'export_path') and provides context, but the input schema already covers them with 100% coverage. The description does not add significant semantics beyond what the schema descriptions offer, so it meets the baseline of 3.
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 characterizes the signal on a channel and is the 'FLAGSHIP goal-level tool'. It details the multi-step algorithm (probe, vertical fit, etc.) and distinguishes itself from simpler sibling tools like 'measure' or 'acq_run' by being comprehensive and iterative.
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 calls it the 'FLAGSHIP goal-level tool', implying it is the primary tool for signal characterization, but it does not explicitly state when to use simpler alternatives or when not to use this tool. It lacks explicit usage guidance compared to alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return the connected instrument's identity (vendor, model, serial, firmware).
Takes no arguments; requires a prior self_config.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description discloses that the tool takes no arguments and requires self_config. It does not mention side effects or error conditions, but for a simple identity retrieval this is minimally 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?
The description is extremely concise: two sentences, no fluff. The first sentence states purpose, the second adds constraints.
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 the tool's simplicity and presence of an output schema, the description adequately covers what it returns and the prerequisite. It could mention that it is a read-only operation, but not essential.
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?
There are no parameters and schema coverage is 100%. The description adds value by explicitly stating 'Takes no arguments', which reinforces 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?
The description clearly states the tool returns the instrument's identity including vendor, model, serial, and firmware. It distinguishes from sibling tools which perform configuration or 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?
The description explicitly mentions that it requires a prior self_config, giving clear context for when to use it. However, it does not provide exclusions or alternatives for 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.
Take a single measurement of one quantity on one channel.
| Name | Required | Description | Default |
|---|---|---|---|
| kind | Yes | Measurement to take. One of: 'vpp', 'vrms', 'vmax', 'vmin', 'frequency', 'period', 'duty', 'rise_time', 'fall_time'. | |
| channel | Yes | Analog channel to measure, 1-based (1–4). |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only describes the action without revealing side effects, permissions, or return behavior. For a read-like operation, minimal transparency is acceptable but not sufficient.
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 a single, concise sentence with no wasted words. It is front-loaded with the core action. Could benefit from a slightly more structured format, but efficient overall.
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 low complexity (2 required params), full schema coverage, and the presence of an output schema, the description provides adequate information for a tool with such straightforward semantics.
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%, so the input schema already documents both parameters (kind with allowed values, channel with range). The description adds no additional meaning beyond the schema, meriting a baseline score of 3.
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's action ('Take a single measurement') and resource ('one quantity on one channel'), effectively distinguishing it from siblings like measure_series which take multiple measurements.
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 implies usage for a single measurement on one channel, but does not explicitly state when to avoid this tool or mention alternatives. The context of sibling tools provides some contrast, but the description itself lacks explicit guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Poll one measurement repeatedly, returning a short time series.
Useful for watching a value drift or settle (e.g. a ramping duty cycle).
``interval_s`` is honored via the instrument's settle hook so the mock stays
instant in tests while real hardware actually waits between reads.
| Name | Required | Description | Default |
|---|---|---|---|
| kind | Yes | Measurement to take. One of: 'vpp', 'vrms', 'vmax', 'vmin', 'frequency', 'period', 'duty', 'rise_time', 'fall_time'. | |
| channel | Yes | Analog channel to measure, 1-based (1–4). | |
| samples | No | How many readings to take (>=1). Default 5. | |
| interval_s | No | Delay in seconds between readings. 0 (default) polls as fast as possible. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It discloses the behavior of interval_s in test vs real hardware, indicating the tool respects the settle hook, making mock instant. This adds behavioral context 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences plus an embedded code block, all concisely front-loaded. First sentence states purpose, second gives use case, third explains key parameter behavior with a test vs hardware distinction. 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 4 parameters, 2 required, and an output schema (context signal), the description covers the key aspects: polling nature, sampling behavior, and parameter rationale. It might lack prerequisites (e.g., prior configuration), but sibling tools imply those steps exist.
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%, baseline 3. The description adds value by clarifying that interval_s is honored via the instrument's settle hook, and that 0 polls as fast as possible. It also uses context to explain the behavior, which is not fully captured in the 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 states the verb 'poll' and resource 'measurement repeatedly, returning a short time series'. It distinguishes from siblings like measure_snapshot by emphasizing repeated readings over time.
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 explicitly states it's 'useful for watching a value drift or settle' with a concrete example. It also explains when interval_s matters (honored via settle hook) but doesn't explicitly list when not to use it or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Take several measurements at once on one channel (one read per quantity).
| Name | Required | Description | Default |
|---|---|---|---|
| kinds | No | Which measurements to take together, e.g. ['vpp', 'frequency']. None uses the default set (vpp, vrms, frequency, period, duty). | |
| channel | Yes | Analog channel to measure, 1-based (1–4). |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It only mentions 'one read per quantity' but does not disclose side effects, permissions needed, or whether it's a read-only operation. This is insufficient.
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 a single sentence that conveys the core purpose concisely. It is efficient but could benefit from additional structure or details.
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 functionality but fails to provide context for selecting this tool among siblings, such as whether it is a one-shot snapshot versus continuous series. Output schema exists, so return values are not required, but sibling differentiation is missing.
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 100%, so the schema already documents both parameters. The description adds no additional meaning beyond the schema, justifying the baseline score of 3.
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 takes several measurements at once on one channel, which distinguishes it from a single measurement. However, it does not explicitly differentiate from the sibling tool measure_series, which also takes multiple measurements.
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 is provided on when to use this tool versus alternatives like measure_series or measure. The description lacks context about prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Discover/connect an instrument and attach it to the session.
Call this first — every other tool needs a connected instrument. Runs the
transport cascade (USB → LAN → manual host); pass ``host`` to skip discovery
and target a known address.
| Name | Required | Description | Default |
|---|---|---|---|
| host | No | Optional instrument address (IP/hostname, or a full VISA resource string) to connect to directly. None runs auto-discovery (USB, then LAN). |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries the burden. It explains the transport cascade and skip behavior, but lacks details on failure modes, timeouts, or side effects like disconnecting existing sessions.
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 sentences plus a tech note with no unnecessary words. Purpose is front-loaded, and every sentence is meaningful.
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 the tool's complexity (with a discovery cascade) and the presence of an output schema, the description covers main usage and parameter meaning. It is nearly complete, though it omits error handling details.
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 clear description of the host parameter. The description adds value by explaining how to use it to skip discovery, enhancing the 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?
The description uses specific verbs: 'Discover/connect an instrument and attach it to the session.' It clearly differentiates the tool from sibling tools which focus on acquisition, measurement, and configuration tasks.
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 'Call this first — every other tool needs a connected instrument.' Provides guidance on using the host parameter to skip discovery, offering clear context for when to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Set a channel's vertical configuration (enable, V/div, offset, coupling).
Only the arguments you pass are changed; omit any to leave it as-is. Use this to fit a signal on screen before measuring or capturing.
| Name | Required | Description | Default |
|---|---|---|---|
| scale | No | Vertical scale in volts per division (e.g. 0.5 = 500 mV/div). None leaves it unchanged. | |
| offset | No | Vertical offset in volts, shifting the trace up (+) or down (-). None leaves it unchanged. | |
| channel | Yes | Analog channel to configure, 1-based (1–4). | |
| enabled | No | Turn the channel's display/acquisition on (True) or off (False). None leaves it unchanged. | |
| coupling | No | Input coupling: 'DC', 'AC', or 'GND'. None leaves it unchanged. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries the full burden. It discloses the partial update behavior ('Only the arguments you pass are changed; omit any to leave it as-is'), which is a key behavioral trait. It does not mention side effects or error conditions, but the partial update disclosure is valuable.
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: the first states the purpose, the second explains partial update and use case. Every sentence is essential with no fluff, and the main action is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers purpose, partial update behavior, and a typical use case. It does not explain return values (output schema exists), nor error conditions. Given the moderate complexity and available schema, it is fairly 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 100%, so baseline is 3. The description adds context by grouping parameters under 'vertical configuration' and clarifying partial update, but it does not add meaning beyond the schema's detailed parameter 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 states the tool sets a channel's vertical configuration (enable, V/div, offset, coupling). It distinguishes from sibling tools like acq_configure and set_timebase by specifying the resource (channel) and the specific configuration parameters.
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 explains that only passed arguments are changed (partial update) and suggests using it to fit a signal on screen before measuring or capturing. This provides context but does not explicitly exclude alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Set the horizontal time base (seconds/div and trigger offset).
Controls how many periods of the signal are shown; widen s/div to see slow events, narrow it to resolve fast ones. Shared across all channels.
| Name | Required | Description | Default |
|---|---|---|---|
| scale | No | Horizontal scale in seconds per division (e.g. 1e-3 = 1 ms/div). None leaves it unchanged. | |
| offset | No | Horizontal (trigger) offset in seconds, moving the trigger point left/right. None leaves it unchanged. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full behavioral burden. It discloses that changes are shared across channels but omits potential side effects, destructiveness, or prerequisites. More context on what happens when called (e.g., does it reset other settings?) would improve transparency.
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 front-loaded purpose. Each sentence adds value: first defines the operation, second provides usage context and scope. 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 the tool's simplicity (2 optional params) and presence of an output schema, the description covers key aspects: purpose, usage guidelines, and scope. It could mention typical return value or error states but is mostly 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 100%, with each parameter already explained with units and default behavior. The tool description adds minimal extra meaning (e.g., 'trigger offset' phrasing already in schema), so 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?
The description clearly states it sets horizontal time base (seconds/div and trigger offset) and explains the effect on signal display. It implicitly distinguishes from sibling tools like set_channel and set_trigger by focusing on timebase, but does not explicitly differentiate.
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 provides practical guidance: widen s/div for slow events, narrow for fast ones. It also notes the setting is shared across all channels. However, it lacks explicit when-not-to-use or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Configure the edge trigger (source channel, level, slope).
Sets up a stable trigger so repetitive signals hold still, or so a
single-shot (see acq_single) fires on the right edge of a one-off event.
| Name | Required | Description | Default |
|---|---|---|---|
| level | Yes | Trigger threshold voltage. The scope fires when the source crosses this level in the chosen slope direction. | |
| slope | No | Edge direction to trigger on: 'rising' (default) or 'falling'. | rising |
| source | Yes | Trigger source: analog channel to trigger on (1-based). |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must carry the burden. It describes the action (configuring trigger) and the effect (sets up stable trigger). However, it does not disclose potential side effects (e.g., overriding previous trigger settings) or read-only nature.
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?
Three sentences, no redundancy, front-loaded with purpose. Every sentence adds value.
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 3 parameters and output schema existence, the description sufficiently explains the tool's usage. Could mention the output briefly, but not required due to output schema.
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%, baseline 3. Description adds context for 'level' (threshold voltage) and 'source' (1-based) but largely paraphrases the schema. No additional meaning beyond 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 verb+resource ('configure the edge trigger') and explains the purpose with concrete use cases (stabilize repetitive signals, single-shot). Distinguishes from sibling 'acq_single' by mentioning it.
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 clear context for using the tool (stabilizing repetitive signals or for single-shot events) and references sibling 'acq_single'. Could be more explicit about when not to use, but sufficient.
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.
v0.1.1acq_configure7 fields changedInput schema / properties / acq_typeAdded value: +{
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "Acquisition mode: 'NORMal', 'AVERages', 'PEAK', or 'HRESolution'. None leaves it unchanged.",
+ "title": "Acq Type"
+}Input schema / properties / argsRemoved value: -{
- "title": "Args"
-}Input schema / properties / confirmAdded value: +{
+ "default": false,
+ "description": "Safety gate for this disruptive action. Must be True to run — the server refuses the call when False.",
+ "title": "Confirm",
+ "type": "boolean"
+}Input schema / properties / kwargsRemoved value: -{
- "title": "Kwargs"
-}Input schema / properties / memory_depthAdded value: +{
+ "anyOf": [
+ {
+ "type": "integer"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "Record length in sample points (e.g. 12000, 120000, 1200000). None leaves it unchanged.",
+ "title": "Memory Depth"
+}Input schema / requiredRemoved value: -[
- "args",
- "kwargs"
-]Output schema / (root)Previous value: -nullNew value: +{
+ "additionalProperties": true,
+ "title": "set_acquisition_implDictOutput",
+ "type": "object"
+}acq_force5 fields changedInput schema / properties / argsRemoved value: -{
- "title": "Args"
-}Input schema / properties / confirmAdded value: +{
+ "default": false,
+ "description": "Safety gate for this disruptive action. Must be True to run — the server refuses the call when False.",
+ "title": "Confirm",
+ "type": "boolean"
+}Input schema / properties / kwargsRemoved value: -{
- "title": "Kwargs"
-}Input schema / requiredRemoved value: -[
- "args",
- "kwargs"
-]Output schema / (root)Previous value: -nullNew value: +{
+ "additionalProperties": true,
+ "title": "force_trigger_implDictOutput",
+ "type": "object"
+}acq_run5 fields changedInput schema / properties / argsRemoved value: -{
- "title": "Args"
-}Input schema / properties / confirmAdded value: +{
+ "default": false,
+ "description": "Safety gate for this disruptive action. Must be True to run — the server refuses the call when False.",
+ "title": "Confirm",
+ "type": "boolean"
+}Input schema / properties / kwargsRemoved value: -{
- "title": "Kwargs"
-}Input schema / requiredRemoved value: -[
- "args",
- "kwargs"
-]Output schema / (root)Previous value: -nullNew value: +{
+ "additionalProperties": true,
+ "title": "run_implDictOutput",
+ "type": "object"
+}acq_single5 fields changedInput schema / properties / argsRemoved value: -{
- "title": "Args"
-}Input schema / properties / confirmAdded value: +{
+ "default": false,
+ "description": "Safety gate for this disruptive action. Must be True to run — the server refuses the call when False.",
+ "title": "Confirm",
+ "type": "boolean"
+}Input schema / properties / kwargsRemoved value: -{
- "title": "Kwargs"
-}Input schema / requiredRemoved value: -[
- "args",
- "kwargs"
-]Output schema / (root)Previous value: -nullNew value: +{
+ "additionalProperties": true,
+ "title": "single_implDictOutput",
+ "type": "object"
+}acq_stop5 fields changedInput schema / properties / argsRemoved value: -{
- "title": "Args"
-}Input schema / properties / confirmAdded value: +{
+ "default": false,
+ "description": "Safety gate for this disruptive action. Must be True to run — the server refuses the call when False.",
+ "title": "Confirm",
+ "type": "boolean"
+}Input schema / properties / kwargsRemoved value: -{
- "title": "Kwargs"
-}Input schema / requiredRemoved value: -[
- "args",
- "kwargs"
-]Output schema / (root)Previous value: -nullNew value: +{
+ "additionalProperties": true,
+ "title": "stop_implDictOutput",
+ "type": "object"
+}capability_report4 fields changedInput schema / properties / argsRemoved value: -{
- "title": "Args"
-}Input schema / properties / kwargsRemoved value: -{
- "title": "Kwargs"
-}Input schema / requiredRemoved value: -[
- "args",
- "kwargs"
-]Output schema / (root)Previous value: -nullNew value: +{
+ "additionalProperties": true,
+ "title": "capability_report_implDictOutput",
+ "type": "object"
+}capture_aligned7 fields changedInput schema / properties / argsRemoved value: -{
- "title": "Args"
-}Input schema / properties / channelsAdded value: +{
+ "description": "Analog channels to capture together, e.g. [1, 2]. Read on the shared time base so the traces are time-aligned.",
+ "items": {
+ "type": "integer"
+ },
+ "title": "Channels",
+ "type": "array"
+}Input schema / properties / deepAdded value: +{
+ "default": false,
+ "description": "If True, read deep memory for each channel; if False (default), read the on-screen trace.",
+ "title": "Deep",
+ "type": "boolean"
+}Input schema / properties / include_samplesAdded value: +{
+ "default": false,
+ "description": "If True, include the full time/volts sample arrays. Default False returns only a summary (point count, sample rate, start/end time) to avoid flooding the context.",
+ "title": "Include Samples",
+ "type": "boolean"
+}Input schema / properties / kwargsRemoved value: -{
- "title": "Kwargs"
-}Input schema / requiredPrevious value: -[
- "args",
- "kwargs"
-]New value: +[
+ "channels"
+]Output schema / (root)Previous value: -nullNew value: +{
+ "additionalProperties": true,
+ "title": "capture_aligned_implDictOutput",
+ "type": "object"
+}capture_memory7 fields changedInput schema / properties / argsRemoved value: -{
- "title": "Args"
-}Input schema / properties / channelAdded value: +{
+ "description": "Analog channel to read, 1-based (1–4).",
+ "title": "Channel",
+ "type": "integer"
+}Input schema / properties / include_samplesAdded value: +{
+ "default": false,
+ "description": "If True, include the full time/volts sample arrays. Default False returns only a summary (point count, sample rate, start/end time) to avoid flooding the context.",
+ "title": "Include Samples",
+ "type": "boolean"
+}Input schema / properties / kwargsRemoved value: -{
- "title": "Kwargs"
-}Input schema / properties / pointsAdded value: +{
+ "anyOf": [
+ {
+ "type": "integer"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "Number of deep-memory sample points to read back. None reads the full acquisition record.",
+ "title": "Points"
+}Input schema / requiredPrevious value: -[
- "args",
- "kwargs"
-]New value: +[
+ "channel"
+]Output schema / (root)Previous value: -nullNew value: +{
+ "additionalProperties": true,
+ "title": "capture_memory_implDictOutput",
+ "type": "object"
+}capture_screen6 fields changedInput schema / properties / argsRemoved value: -{
- "title": "Args"
-}Input schema / properties / channelAdded value: +{
+ "description": "Analog channel to read, 1-based (1–4).",
+ "title": "Channel",
+ "type": "integer"
+}Input schema / properties / include_samplesAdded value: +{
+ "default": false,
+ "description": "If True, include the full time/volts sample arrays. Default False returns only a summary (point count, sample rate, start/end time) to avoid flooding the context.",
+ "title": "Include Samples",
+ "type": "boolean"
+}Input schema / properties / kwargsRemoved value: -{
- "title": "Kwargs"
-}Input schema / requiredPrevious value: -[
- "args",
- "kwargs"
-]New value: +[
+ "channel"
+]Output schema / (root)Previous value: -nullNew value: +{
+ "additionalProperties": true,
+ "title": "capture_screen_implDictOutput",
+ "type": "object"
+}characterize_signal6 fields changedInput schema / properties / argsRemoved value: -{
- "title": "Args"
-}Input schema / properties / channelAdded value: +{
+ "description": "Analog channel to characterize, 1-based (1–4).",
+ "title": "Channel",
+ "type": "integer"
+}Input schema / properties / export_pathAdded value: +{
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "Optional filesystem path to render the fitted deep-memory capture to a PNG. None skips the export.",
+ "title": "Export Path"
+}Input schema / properties / kwargsRemoved value: -{
- "title": "Kwargs"
-}Input schema / requiredPrevious value: -[
- "args",
- "kwargs"
-]New value: +[
+ "channel"
+]Output schema / (root)Previous value: -nullNew value: +{
+ "additionalProperties": true,
+ "title": "characterize_signal_implDictOutput",
+ "type": "object"
+}identify4 fields changedInput schema / properties / argsRemoved value: -{
- "title": "Args"
-}Input schema / properties / kwargsRemoved value: -{
- "title": "Kwargs"
-}Input schema / requiredRemoved value: -[
- "args",
- "kwargs"
-]Output schema / (root)Previous value: -nullNew value: +{
+ "additionalProperties": true,
+ "title": "identify_implDictOutput",
+ "type": "object"
+}measure6 fields changedInput schema / properties / argsRemoved value: -{
- "title": "Args"
-}Input schema / properties / channelAdded value: +{
+ "description": "Analog channel to measure, 1-based (1–4).",
+ "title": "Channel",
+ "type": "integer"
+}Input schema / properties / kindAdded value: +{
+ "description": "Measurement to take. One of: 'vpp', 'vrms', 'vmax', 'vmin', 'frequency', 'period', 'duty', 'rise_time', 'fall_time'.",
+ "title": "Kind",
+ "type": "string"
+}Input schema / properties / kwargsRemoved value: -{
- "title": "Kwargs"
-}Input schema / requiredPrevious value: -[
- "args",
- "kwargs"
-]New value: +[
+ "channel",
+ "kind"
+]Output schema / (root)Previous value: -nullNew value: +{
+ "additionalProperties": true,
+ "title": "measure_implDictOutput",
+ "type": "object"
+}measure_series8 fields changedInput schema / properties / argsRemoved value: -{
- "title": "Args"
-}Input schema / properties / channelAdded value: +{
+ "description": "Analog channel to measure, 1-based (1–4).",
+ "title": "Channel",
+ "type": "integer"
+}Input schema / properties / interval_sAdded value: +{
+ "default": 0,
+ "description": "Delay in seconds between readings. 0 (default) polls as fast as possible.",
+ "title": "Interval S",
+ "type": "number"
+}Input schema / properties / kindAdded value: +{
+ "description": "Measurement to take. One of: 'vpp', 'vrms', 'vmax', 'vmin', 'frequency', 'period', 'duty', 'rise_time', 'fall_time'.",
+ "title": "Kind",
+ "type": "string"
+}Input schema / properties / kwargsRemoved value: -{
- "title": "Kwargs"
-}Input schema / properties / samplesAdded value: +{
+ "default": 5,
+ "description": "How many readings to take (>=1). Default 5.",
+ "minimum": 1,
+ "title": "Samples",
+ "type": "integer"
+}Input schema / requiredPrevious value: -[
- "args",
- "kwargs"
-]New value: +[
+ "channel",
+ "kind"
+]Output schema / (root)Previous value: -nullNew value: +{
+ "additionalProperties": true,
+ "title": "polled_series_implDictOutput",
+ "type": "object"
+}measure_snapshot6 fields changedInput schema / properties / argsRemoved value: -{
- "title": "Args"
-}Input schema / properties / channelAdded value: +{
+ "description": "Analog channel to measure, 1-based (1–4).",
+ "title": "Channel",
+ "type": "integer"
+}Input schema / properties / kindsAdded value: +{
+ "anyOf": [
+ {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "Which measurements to take together, e.g. ['vpp', 'frequency']. None uses the default set (vpp, vrms, frequency, period, duty).",
+ "title": "Kinds"
+}Input schema / properties / kwargsRemoved value: -{
- "title": "Kwargs"
-}Input schema / requiredPrevious value: -[
- "args",
- "kwargs"
-]New value: +[
+ "channel"
+]Output schema / (root)Previous value: -nullNew value: +{
+ "additionalProperties": true,
+ "title": "snapshot_implDictOutput",
+ "type": "object"
+}self_config5 fields changedInput schema / properties / argsRemoved value: -{
- "title": "Args"
-}Input schema / properties / hostAdded value: +{
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "Optional instrument address (IP/hostname, or a full VISA resource string) to connect to directly. None runs auto-discovery (USB, then LAN).",
+ "title": "Host"
+}Input schema / properties / kwargsRemoved value: -{
- "title": "Kwargs"
-}Input schema / requiredRemoved value: -[
- "args",
- "kwargs"
-]Output schema / (root)Previous value: -nullNew value: +{
+ "additionalProperties": true,
+ "title": "self_config_implDictOutput",
+ "type": "object"
+}set_channel9 fields changedInput schema / properties / argsRemoved value: -{
- "title": "Args"
-}Input schema / properties / channelAdded value: +{
+ "description": "Analog channel to configure, 1-based (1–4).",
+ "title": "Channel",
+ "type": "integer"
+}Input schema / properties / couplingAdded value: +{
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "Input coupling: 'DC', 'AC', or 'GND'. None leaves it unchanged.",
+ "title": "Coupling"
+}Input schema / properties / enabledAdded value: +{
+ "anyOf": [
+ {
+ "type": "boolean"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "Turn the channel's display/acquisition on (True) or off (False). None leaves it unchanged.",
+ "title": "Enabled"
+}Input schema / properties / kwargsRemoved value: -{
- "title": "Kwargs"
-}Input schema / properties / offsetAdded value: +{
+ "anyOf": [
+ {
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "Vertical offset in volts, shifting the trace up (+) or down (-). None leaves it unchanged.",
+ "title": "Offset"
+}Input schema / properties / scaleAdded value: +{
+ "anyOf": [
+ {
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "Vertical scale in volts per division (e.g. 0.5 = 500 mV/div). None leaves it unchanged.",
+ "title": "Scale"
+}Input schema / requiredPrevious value: -[
- "args",
- "kwargs"
-]New value: +[
+ "channel"
+]Output schema / (root)Previous value: -nullNew value: +{
+ "additionalProperties": true,
+ "title": "set_channel_implDictOutput",
+ "type": "object"
+}set_timebase6 fields changedInput schema / properties / argsRemoved value: -{
- "title": "Args"
-}Input schema / properties / kwargsRemoved value: -{
- "title": "Kwargs"
-}Input schema / properties / offsetAdded value: +{
+ "anyOf": [
+ {
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "Horizontal (trigger) offset in seconds, moving the trigger point left/right. None leaves it unchanged.",
+ "title": "Offset"
+}Input schema / properties / scaleAdded value: +{
+ "anyOf": [
+ {
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "Horizontal scale in seconds per division (e.g. 1e-3 = 1 ms/div). None leaves it unchanged.",
+ "title": "Scale"
+}Input schema / requiredRemoved value: -[
- "args",
- "kwargs"
-]Output schema / (root)Previous value: -nullNew value: +{
+ "additionalProperties": true,
+ "title": "set_timebase_implDictOutput",
+ "type": "object"
+}set_trigger7 fields changedInput schema / properties / argsRemoved value: -{
- "title": "Args"
-}Input schema / properties / kwargsRemoved value: -{
- "title": "Kwargs"
-}Input schema / properties / levelAdded value: +{
+ "description": "Trigger threshold voltage. The scope fires when the source crosses this level in the chosen slope direction.",
+ "title": "Level",
+ "type": "number"
+}Input schema / properties / slopeAdded value: +{
+ "default": "rising",
+ "description": "Edge direction to trigger on: 'rising' (default) or 'falling'.",
+ "title": "Slope",
+ "type": "string"
+}Input schema / properties / sourceAdded value: +{
+ "description": "Trigger source: analog channel to trigger on (1-based).",
+ "title": "Source",
+ "type": "integer"
+}Input schema / requiredPrevious value: -[
- "args",
- "kwargs"
-]New value: +[
+ "source",
+ "level"
+]Output schema / (root)Previous value: -nullNew value: +{
+ "additionalProperties": true,
+ "title": "set_trigger_implDictOutput",
+ "type": "object"
+}v0.1.0acq_configureacq_forceacq_runacq_singleacq_stopcapability_reportcapture_alignedcapture_memorycapture_screencharacterize_signalidentifymeasuremeasure_seriesmeasure_snapshotself_configset_channelset_timebaseset_triggerScored across 18 tools
Each tool targets a distinct oscilloscope operation. Acquisition, capture, measurement, and configuration tools have clear, non-overlapping purposes. Even similar tools like acq_run and acq_single are differentiated by continuous vs single-shot acquisition.
Tools predominantly follow a consistent verb_noun pattern (e.g., set_channel, capture_screen). Minor deviations like 'identify' and 'self_config' slightly break the pattern but remain intuitive. Overall, naming is predictable and readable.
18 tools comprehensively cover essential oscilloscope operations without redundancy. The count is well-scoped for a domain-specific server, providing enough granularity for complex workflows while remaining manageable.
Core lifecycle tasks (connect, configure, acquire, capture, measure) are fully covered. Advanced features like FFT or automated calibration are absent but not critical for basic SCPI control. Minor gaps exist but do not hinder primary use cases.
MCP server for building and testing AI agents with multi-model experimentation and insights.
The Remote MCP server acts as a standardized bridge between LLM applications (like Claude, ChatGPT, and Cursor) and external services, enabling AI agents to access external tools and resources. Its primary capability is providing a centralized search tool to discover other MCP servers and their respective tools. Unlike local implementations, it runs remotely with OAuth authentication and permission controls for security.
MCP server connecting AI agents to 100+ apps (Gmail, Slack, Notion, GitHub) via one-click OAuth.
MCP server enabling AI agents to manage Bitrix24 features via standardized protocol
