Thorlabs Optical Power Meter

Thorlabs Optical Power Meter — MCP Server

Let an AI agent read laser power, log stability and warm-up drift, set the wavelength correction, averaging and range, and dark-zero the sensor on Thorlabs optical power meters through their documented SCPI command set over USB (USBTMC / VISA).

Try it without hardware

uvx labmcp-thorlabs-pm --simulate --check

uvx labmcp-thorlabs-pm --simulate --option sim_sensor=S302C --check # thermal sensor head

The simulator is a PM100D with an S120C photodiode (or S302C thermopile) looking at a 1.234 mW, 632.8 nm HeNe laser. Setting the wrong wavelength on the photodiode gives a proportionally wrong reading, as on the real bench.

Connect your power meter

1. Driver. Thorlabs meters enumerate as USB Test & Measurement Class (USBTMC) devices, vendor ID 0x1313.

• Windows: the Thorlabs driver (TLPM / Thorlabs VISA) is *not* visible to PyVISA. Install the free NI-VISA runtime, then switch the meter to the NI-VISA driver with the Thorlabs Driver Switcher (installed with the Thorlabs Optical Power Monitor software), and start the server with ?backend=@ivi (see below). This is the route Thorlabs documents for PyVISA.
• Linux: pyvisa-py talks USBTMC directly (installed with this package). Give your user access to the device, e.g. /etc/udev/rules.d/99-thorlabs-pm.rules: SUBSYSTEM=="usb", ATTR{idVendor}=="1313", MODE="0666" then sudo udevadm control --reload-rules and re-plug the meter. NI-VISA also works (?backend=@ivi).
• macOS: pyvisa-py + libusb (brew install libusb); NI-VISA is an alternative.

1. Find the resource string: uvx labmcp ports (or python -m pyvisa info). It looks like USB0::0x1313::0x8078::P0012345::INSTR (the product ID depends on the model: PM100D 0x8078, PM100USB 0x8072).
2. Test the connection:

   uvx labmcp-thorlabs-pm --address USB0::0x1313::0x8078::P0012345::INSTR --check

uvx labmcp-thorlabs-pm --address "visa://USB0::0x1313::0x8078::P0012345::INSTR?backend=@ivi" --check # NI-VISA

   For the second input of a PM5020 add `--option channel=2`.

Add to your MCP client

Claude Code

claude mcp add power-meter -- uvx labmcp-thorlabs-pm --address USB0::0x1313::0x8078::P0012345::INSTR

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

{

"mcpServers": { "power-meter": { "command": "uvx", "args": ["labmcp-thorlabs-pm", "--address", "USB0::0x1313::0x8078::P0012345::INSTR"] } } }

Add --read-only to allow readings but block wavelength, averaging, range and zero changes. For other clients, generate the snippet with uvx labmcp config thorlabs-pm --address --client vscode (also cursor, codex, claude-code).

Tools

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

A power meter only measures, so this server has no hazard tools. Your laser is the hazard: wear the right eyewear and never exceed the sensor's rated power or power density.

Safety limits

Override at launch: --limit max_series_duration_s=3600. One call can log at most 3640 s (the tool's timeout minus a margin): longer estimates are refused, and a series that runs slower than estimated stops early and returns what it measured (completed: false). save_path must end in .csv and must not exist yet (an existing file is never overwritten); it is checked before logging starts.

Example prompts

• "Set the meter to 1064 nm and tell me the power after the objective."
• "Log the laser power every 2 s for 10 minutes and report the RMS and peak-to-peak stability. Save the data to ~/data/laser_warmup.csv."
• "I've capped the sensor. Zero it, then I'll remove the cap and you read the power."
• "Measure the transmission of this ND filter: read the power without it, then again after I insert it, and give me the optical density."
• "Is the thermal sensor head still warming up? Read its temperature every minute until it's stable."

Notes

• Wavelength matters. Photodiode responsivity varies by a factor of several across the sensor's range, so a wrong wavelength setting gives a wrong power. The server sends whole nanometres (the PM400/PM101/PM5020 references specify an integer), so 632.8 nm is set as 633 nm. That changes the responsivity by far less than the sensor's calibration uncertainty.
• Units. MEAS:POW? answers in the meter's configured unit (W or dBm). The driver reads SENS:POW:UNIT? first and always returns watts, so a front-panel unit change can't mislead the agent.
• Out of range. The meter answers INFINITY / 9.9E37 when the signal exceeds a manually selected range. The server reports this as an error that suggests auto-ranging.
• Zeroing (SENS:CORR:COLL:ZERO) runs in the background. The server polls …:ZERO:STAT?, checks the error queue, and returns the zero value (…:ZERO:MAGN?). Zero values are lost when the meter reboots.
• Energy (pyroelectric) sensors are recognised but not supported: single-pulse energy measurement needs a trigger/fetch workflow that this server doesn't implement yet.
• Averaging is SENS:AVER:COUN. One sample takes ~3 ms on the PM100 series and 1 ms on the PM400/PM101/PM5020. The reply timeout scales with the averaging count.
• PM101 and PM5020: Thorlabs' command references for these list exactly the commands used here. The PM5020 adds a channel suffix (SENS2, MEAS2, SYST:SENS2:IDN?), selected with --option channel=2. Neither has been tested yet, and PM5020 LAN/serial connections have not been tried. The PM100D's Windows TLPM DLL driver is not used; this server speaks SCPI only.
• The simulator's error replies for out-of-range values (-222,"Data out of range") use the standard SCPI code. The Thorlabs documents only list -113,"Undefined header" explicitly.

Hardware verification