Bench DC Power Supply — MCP Server

Let an AI agent set voltages and current limits, switch outputs on and off, watch constant-voltage / constant-current behaviour and configure over-voltage / over-current protection on programmable DC bench power supplies from Rigol, Siglent and Aim-TTi, using each vendor's documented remote command set. The dialect is detected from *IDN?.

Keysight / Agilent and Rohde & Schwarz supplies are intentionally not covered: both vendors publish official MCP servers. Use the Keysight MCP Server for Instrument Control or the MCP server included in Rohde & Schwarz RsInstrument. This server refuses to connect to them.

Try it without hardware

uvx labmcp-bench-psu --simulate --check                                        # Rigol DP832
uvx labmcp-bench-psu --simulate --option dialect=siglent --check               # Siglent SPD3303X
uvx labmcp-bench-psu --simulate --option dialect=tti --option sim_model=MX100TP --check

The simulated outputs drive resistive loads (CH1 10 Ω, CH2 100 Ω, CH3 open), so you can watch the CV → CC crossover and trip OVP/OCP.

Connect your instrument

1. Instrument setup: enable the interface you use (Rigol: Utility → I/O Config; Siglent: System → Interface; Aim-TTi: LAN works out of the box, USB appears as a virtual COM port). Note the IP address or VISA resource string.
2. Find the address: uvx labmcp ports (serial) or python -m pyvisa info / your VISA vendor's tool (USB/LAN).
3. Test the connection:
   bash

   uvx labmcp-bench-psu --address "USB0::0x1AB1::0x0E11::DP8C123456789::INSTR" --check   # Rigol over USB-TMC
   uvx labmcp-bench-psu --address "TCPIP0::192.168.1.50::INSTR" --check                 # any LXI/VXI-11 supply
   uvx labmcp-bench-psu --address tcp://192.168.1.51:5025 --check                       # Siglent raw socket
   uvx labmcp-bench-psu --address tcp://192.168.1.52:9221 --check                       # Aim-TTi raw socket
   uvx labmcp-bench-psu --address /dev/ttyACM0 --check                                  # Aim-TTi USB virtual COM
   uvx labmcp-bench-psu --address "serial://COM3?write_termination=CRLF" --check        # Rigol DP800 RS-232
   

   USB-TMC and VXI-11 addresses use PyVISA (installed with this package; add ?backend=@ivi to use NI-VISA / Keysight IO Libraries instead of pyvisa-py).

Add to your MCP client

Claude Code

claude mcp add psu -- uvx labmcp-bench-psu --address "TCPIP0::192.168.1.50::INSTR" --limit max_voltage_v=12 --limit max_current_a=1

Claude Desktop / Cursor / Windsurf (claude_desktop_config.json, .cursor/mcp.json, …)

{
  "mcpServers": {
    "psu": {
      "command": "uvx",
      "args": ["labmcp-bench-psu", "--address", "TCPIP0::192.168.1.50::INSTR",
               "--limit", "max_voltage_v=12", "--limit", "max_current_a=1"]
    }
  }
}

Add --read-only to allow monitoring only: setpoint changes and output_on are hidden, while output_off and all_outputs_off stay available. For other clients, generate the snippet with uvx labmcp config bench-psu --address TCPIP0::192.168.1.50::INSTR --client vscode.

Tools

get_connection_info, get_command_log and reconnect are built into every LabMCP server.

Safety limits

Override at launch, e.g. --limit max_voltage_v=12 --limit max_current_a=0.5. Setpoints are also checked against each model's settable range. output_on reads the setpoints back from the instrument first, so a value changed on the front panel cannot slip past the limits.

Example prompts

• "Show me all channels of the power supply: setpoints, measured current and whether they're in CV or CC."
• "Set CH1 to 12 V with a 200 mA current limit, set OVP at 13 V, then turn it on and tell me how much current the LED array draws."
• "Ramp CH2 from 0 to 5 V in 0.5 V steps, reading the current at each step, and plot the I-V curve of the load."
• "The heater is drawing more than expected: turn every output off now."
• "Channel 1 tripped. What happened, and is it safe to clear the trip?"

Notes

• Dialect detection: *IDN? manufacturer "RIGOL" → Rigol, "Siglent" → Siglent, "THURLBY THANDAR"/"TTi"/"Aim" → Aim-TTi. Force one with --option dialect=rigol|siglent|tti for rebadged units. Models not in the built-in table are treated as --option channels=N channels with no model maxima (the safety limits still apply).
• Rigol: setpoints via :SOUR<n>:VOLT/CURR, readback via :APPL? CHn and :MEAS:ALL? CHn, mode via :OUTP:MODE? CHn (CV/CC/UR), OVP/OCP via :OUTP:OVP|OCP[:STAT|:VAL|:QUES?]. Trips are cleared with :OUTP:OVP|OCP:CLEAR, which only clears the flag. [:SOUR]:VOLT:PROT:CLE is never sent because the programming guide says it also turns the output on. DP831 CH3 is a negative output: give negative voltages (not yet verified on hardware). Over RS-232 the DP800 needs CR LF line endings (?write_termination=CRLF).
• Siglent: SPD3303X/X-E have no programmable OVP/OCP and report output state and CV/CC only through the SYST:STAT? status word (CH1/CH2). CH3 is fixed (2.5/3.3/5 V by front-panel switch) and can only be switched on/off; its state is not readable. SPD1000X has OVP/OCP levels only (always armed, trip state not readable). The error reply format (0 No Error) is not SCPI-standard, so settings are verified by reading them back. The server pauses 0.1 s after each command to Siglent supplies (--option write_delay_s= to change); Siglent's own examples wait between commands, but the required delay is not documented.
• Aim-TTi: there is no live CV/CC query, so mode is inferred from readback vs setpoints (mode_source: "inferred"). Trip flags come from the LSR<n>? limit event register, which latches events and is cleared by reading it. CPX/QL/PL-P protection is always armed (levels only); MX models can also switch OVP/OCP on/off. TRIPRST clears trips on all outputs (not documented for MX100T/TP). Original QL P/T models have no output-state query, so their output_on is reported as unknown. OPALL 0 is sent first in all_outputs_off, then every output individually.
• Tracking / series / parallel modes, timers, sequences, remote sense and saved set-ups are not exposed. Put the supply in independent mode before handing it to an agent.
• GW Instek GPP and B&K Precision 9130/9140 supplies are not supported yet: too many reply formats are undocumented in their manuals to implement them safely.

Hardware verification