rigol-oscilloscope-mcp

configure_afg

Set signal parameters like waveform, amplitude, frequency, phase, duty, or modulation on the built-in function generator without changing output state. Use enable_afg to emit the configured waveform.

Instructions

Configure the built-in function generator (AFG). Omitted items are left unchanged.

This never turns the generator output on or off. The output state is not touched at all, so nothing new reaches the wiring: a configured generator only emits a signal once its output is enabled with the separate, confirmation-gated tool enable_afg (and disable_afg turns it off again). Read the current output state with get_afg_state.

channel is the generator channel (1 or 2 on MHO98; see get_capabilities afg_channels). Specify at least one item to change.

waveform is sine / square / ramp / noise / dc / arb / exp_rise / exp_fall / ecg / gaussian / lorentz / haversine / sinc. amplitude_vpp is the peak-to-peak amplitude in volts (not the peak and not RMS), offset_v the DC offset in volts, frequency_hz the frequency in hertz, phase_deg the phase in degrees (0-360), duty_percent the duty cycle of the square wave (1-99) and symmetry_percent the symmetry of the ramp (0-100). Duty and symmetry are stored independently of the current waveform, so they can be set at any time.

impedance is "highz" or "50" and is the GENERATOR's own output impedance setting, i.e. the load the amplitude is calibrated for. It has nothing to do with the oscilloscope input impedance of configure_channel.

The frequency and amplitude limits depend on the installed options and on impedance, and the instrument clamps an out-of-range value silently (no error is reported): always compare applied (the read-back value) against requested. Writing a frequency while the waveform is dc or noise is rejected by the instrument.

arb_file selects an existing arbitrary waveform file already stored on the instrument (local C:/... or USB D:/...), e.g. arb_file="D:/my.csv" together with waveform="arb". This server never creates, uploads or deletes instrument files - it only selects one that is already there.

modulation configures AM/FM/PM (internal source only; there is no external modulation input). Give a dict with any of: enabled (bool), type ("am"/"fm"/"pm"), am_depth_percent (0-120), fm_deviation_hz (>0), pm_deviation_deg (0-360), frequency_hz (the MODULATING frequency, not the carrier - 2 mHz to 1 MHz), waveform (sine/square/triangle/upramp/ dnramp/noise, the modulating waveform). frequency_hz and waveform are routed to the type given in the same call, or otherwise to whatever type is currently set on the instrument. The instrument silently ignores modulation parameter writes while modulation is off, so pass enabled=true together with the parameters (the server sends the enable before the parameters); parameters alone are rejected while modulation is off. Enabling modulation does NOT turn the output on, but if the output is already on, modulation takes effect immediately.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`channel`	No
`arb_file`	No
`offset_v`	No
`waveform`	No
`impedance`	No
`phase_deg`	No
`modulation`	No
`duty_percent`	No
`frequency_hz`	No
`amplitude_vpp`	No
`symmetry_percent`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedv0.1.4Aug 29, 2026

addedInput schema / properties / arb_file

Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Arb File"
+}

addedInput schema / properties / modulation

Added value: +{
+  "anyOf": [
+    {
+      "additionalProperties": true,
+      "type": "object"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Modulation"
+}

First observedv0.1.0Aug 26, 2026

TDQS

A5/5.0

Behavior5/5

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

With no annotations provided, the description carries the full burden, and it does so thoroughly. It discloses silent clamping with a recommendation to compare against read-back values, rejection of frequency writes for dc/noise, the server's refusal to manage instrument files, and modulation parameter behavior including silent ignoring when off and the server sending enable before parameters.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is long, but the complexity of an 11-parameter AFG configuration with modulation and impedance semantics justifies it. It is front-loaded with the most critical behavioral fact (output state is never touched), and each paragraph is organized around a coherent topic with no filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a complex tool with no output schema and no annotations, the description covers all necessary context: parameter constraints, side effects, related tools, workflow ordering, edge cases, and silent-failure risks. An agent has everything needed to invoke this tool correctly and to know what to verify afterward.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must fully compensate, and it does. Every parameter is explained with units, ranges, allowed values, and important distinctions such as amplitude being peak-to-peak rather than RMS and impedance being the generator's own output impedance rather than scope input impedance.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb and resource: 'Configure the built-in function generator (AFG)' and immediately clarifies that omitted items are left unchanged. It also distinguishes itself from the sibling tools by explicitly stating it never turns the output on or off, and by referencing enable_afg, disable_afg, and get_afg_state.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives explicit when-not guidance: it never affects output state, so the agent should use enable_afg/disable_afg for output power control and get_afg_state for reading output state. It also clarifies that the AFG impedance parameter is unrelated to configure_channel, preventing misuse.

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

configure_afg

Instructions

Input Schema

Schema Changelog

TDQS

Other Tools