Skip to main content

Lake Shore Temperature Controller — MCP Server

Let an AI agent read every sensor on your cryostat, check heater status, set setpoints, ramps, heater ranges and PID values, wait for the temperature to settle, and switch all heaters off on Lake Shore Cryotronics Model 335, 336 and 350 temperature controllers.

Package labmcp-lakeshore
Instruments Model 335 (2 inputs, 2 outputs), Model 336 (4 inputs, 4 outputs), Model 350 (4 inputs, 4 outputs)
Interfaces USB (virtual COM port), Ethernet (336 and 350, TCP port 7777), IEEE-488 (GPIB via VISA)
Protocol Lake Shore ASCII commands, chapter 6 of the Model 336 (rev. 2.3), Model 335 (rev. 1.6) and Model 350 (rev. 1.7) user's manuals
Status 🧪 simulated: tested against a wire-level simulator with a thermal model, not yet verified on hardware. Report a hardware test

Try it without hardware

uvx labmcp-lakeshore --simulate --check
uvx labmcp-lakeshore --simulate --option sim_model=350 --option sim_speed=20 --check

The simulator models a small cryostat at 4.2 K: a stage (inputs A diode and C Cernox-like, heated by output 1) and a sample (input B Pt-100, heated by output 2), with Lake Shore's PID law and setpoint ramping. sim_speed makes simulated time run faster than real time.

Connect your controller

The model is detected from *IDN?; other Lake Shore models (325, 331, 340, 372, ...) are refused.

  1. Pick the interface in the controller's Interface menu (only one remote interface is active at a time).
  2. USB: install the Lake Shore USB driver (Windows Update, or lakeshore.com). The port runs at a fixed 57600 baud, 7 data bits, odd parity, 1 stop bit; the server sets this automatically.
  3. Ethernet (336, 350): configure the IP address on the front panel; the command port is TCP 7777 (two connections at most).
  4. Test the connection:
    uvx labmcp-lakeshore --address /dev/ttyACM0 --check          # Linux
    uvx labmcp-lakeshore --address /dev/tty.usbmodemXXXX --check # macOS
    uvx labmcp-lakeshore --address COM5 --check                  # Windows
    uvx labmcp-lakeshore --address tcp://192.168.1.40:7777 --check
    uvx labmcp-lakeshore --address GPIB0::12::INSTR --check
    

Add to your MCP client

Claude Code

claude mcp add cryostat -- uvx labmcp-lakeshore --address tcp://192.168.1.40:7777

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

{
  "mcpServers": {
    "cryostat": {
      "command": "uvx",
      "args": ["labmcp-lakeshore", "--address", "tcp://192.168.1.40:7777"]
    }
  }
}

Add --read-only to allow reading temperatures and heater status but block setpoint, ramp, range and PID changes (all_heaters_off stays available). For other clients, generate the snippet with uvx labmcp config lakeshore --address tcp://192.168.1.40:7777 --client vscode (also cursor, codex, claude-code).

Tools

Tool Kind Description
all_heaters_off 🛑 safety Turn every output off (heater range 0 on outputs 1-4), like the front-panel All Off key, and stop any running wait. Reports the read-back range of each output and all_off.
get_command_log 👁 read Return the most recent raw commands sent to / replies received from the instrument (newest last). Useful for debugging and for recording what was done.
get_connection_info 👁 read Report which instrument is connected (identity, address, simulated or real), whether the server is read-only, and the active safety limits. Call this first.
get_heater_status 👁 read Report each output's control mode and input, heater range, output %, setpoint (and in kelvin), ramp state, PID values and heater errors (open/short). Reading a heater error clears it on the controller.
read_temperatures 👁 read Read every (or the selected) sensor input: kelvin, raw sensor units, sensor type, input name and decoded reading status (invalid, under/overrange). Disabled inputs are listed with null readings.
reconnect 🛑 safety Close and re-open the connection to the instrument (e.g. after it was power cycled or a cable was re-plugged).
set_heater_range ⚠️ hazard Set an output's heater range (each step is ~10x more power). Anything above 0 lets the output heat: in closed loop as the PID demands, in open loop at the front-panel manual output. Refused above max_heater_range, or if the setpoint already programmed on a closed-loop, zone or warm-up output is above max_setpoint_k. Start with the lowest range that can reach the setpoint.
set_pid 🎛 control Set the P, I and D values of an output's control loop (Lake Shore conventions).
set_ramp 🎛 control Turn setpoint ramping on or off for an output's control loop and set the rate. With ramping on, the next setpoint change moves the setpoint gradually - gentler on samples and wiring.
set_setpoint ⚠️ hazard Set the control setpoint of an output's loop in kelvin. If setpoint ramping is on, the setpoint moves toward the new value at the ramp rate. Heating only happens if the output is in closed-loop mode and its heater range is not off. Refused above max_setpoint_k.
wait_for_stable_temperature 👁 read Wait until the control input of output has stayed within tolerance_k of the setpoint (and the setpoint is no longer ramping) for stable_for_s, or until timeout_s. Returns whether it stabilised, the final temperature and a downsampled trace. Changes nothing.

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

Safety limits

Limit Default Meaning
max_setpoint_k 325 K Highest setpoint set_setpoint accepts (room temperature plus margin). set_heater_range also reads back the setpoint of a closed-loop, zone or warm-up output before letting it heat, so a higher setpoint entered on the front panel is refused too (as is a setpoint in sensor units, which cannot be checked). Raise it only if your stage, wiring and sensors are rated higher
max_heater_range 3 Highest heater range index. On the 335/336 3 = High (full power); on the 350 ranges go 1-5 in decade steps, so 3 is 1/100 of full power
max_wait_s 3600 s Longest wait_for_stable_temperature call

Override at launch: --limit max_setpoint_k=420 --limit max_heater_range=2.

Example prompts

  • "Read all the temperatures and tell me if any sensor has an error."
  • "Ramp output 1 to 77 K at 2 K/min on the medium range, then wait until input A has been within 50 mK for 5 minutes."
  • "Step the sample from 10 K to 300 K in 10 K steps and tell me when each step is stable." (with max_setpoint_k high enough)
  • "What are the PID settings on loop 1? Reduce P to 30 and keep I and D."
  • "Something's wrong - turn all heaters off."

Notes

  • Setting a setpoint does not start heating; the heater range does. With a range above 0 an output heats as its PID loop demands (closed loop) or at the manual output (open loop). Output modes and control inputs are configured on the front panel; the server does not change them, since pointing a loop at the wrong sensor can cause a thermal runaway.
  • Setpoints are always given in kelvin. SETP uses the preferred units of the loop's control input: the server converts for Celsius and refuses when the input is set to sensor units.
  • Every command is followed by *ESR?; command (CME) and execution (EXE) errors are reported instead of being ignored. The server leaves at least 50 ms between messages, as the manuals require (--option min_interval_s=).
  • get_heater_status reads HTRST?, which clears a latched heater open/short error on the controller.
  • wait_for_stable_temperature needs the setpoint to have stopped ramping (RAMPST?) as well as the temperature to be in tolerance. all_heaters_off stops a running wait.
  • all_heaters_off sends RANGE n,0 to every output and reads it back, like the front-panel All Off key. Every output is tried even if another fails; all_off is true only when every output read back as off. It does not change setpoints or output modes. Consider also setting a hardware temperature limit (TLIMIT, front panel) as a last line of defence.
  • The 3062 scanner option (inputs D1-D5), zone tables, autotune, curves, alarms and relays are not exposed. The Model 372 AC resistance bridge was not verified and is refused at connect time.

Hardware verification

Model Firmware Interface Verified by Date
none yet: be the first

Release files for labmcp-lakeshore 0.1.3

For a detailed explanation of source distributions (sdists) and built distributions (wheels), please see the package formats documentation.

Source distribution (sdist)

Source distribution for labmcp-lakeshore 0.1.3
File Size Uploaded
labmcp_lakeshore-0.1.3.tar.gz 21.9 kB Details

Built distribution (wheel)

Table of built distributions (wheels) for labmcp-lakeshore 0.1.3
File Interpreter ABI Platform
labmcp_lakeshore-0.1.3-py3-none-any.whl Python 3 none any Details

Total release size: 42.6 kB

Release files / labmcp_lakeshore-0.1.3.tar.gz

Download URL labmcp_lakeshore-0.1.3.tar.gz
Size 21.9 kB
Tags Source
SHA-256 checksum
How to use checksums
36b00ed31b4aab40856a44e7478c51a5054ae6b8e6d223a319fabc7ec5a705fc
BLAKE2b-256 checksum
How to use checksums
f98785ddb9817ba14cff35b6dddc73c57affa07f6508a6afb1401810bab8c90b
Upload date
Uploaded using Trusted Publishing?
What is trusted publishing?
Yes
Uploaded via twine/7.0.0 CPython/3.13.14

Provenance

Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.

PyPI Publish Attestation

PyPI verified that this artifact, at this checksum, originated from the publisher listed below.

Signed by GitHub Actions, verified by PyPI on Sep 26, 2026.

Transparency log

Release files / labmcp_lakeshore-0.1.3-py3-none-any.whl

Download URL labmcp_lakeshore-0.1.3-py3-none-any.whl
Size 20.7 kB
Tags Python 3
SHA-256 checksum
How to use checksums
81a9b40fbc80c683e54c3bd364a49c8fa06e21073b050baaf31f58352e2d26e0
BLAKE2b-256 checksum
How to use checksums
60e4bfd4ce20dde224dcf7cb06ddf15f277af72a518c2d5fa62ec311841c3efa
Upload date
Uploaded using Trusted Publishing?
What is trusted publishing?
Yes
Uploaded via twine/7.0.0 CPython/3.13.14

Provenance

Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.

PyPI Publish Attestation

PyPI verified that this artifact, at this checksum, originated from the publisher listed below.

Signed by GitHub Actions, verified by PyPI on Sep 26, 2026.

Transparency log

Release history Release notifications | RSS feed

This release

0.1.3 This release

2 release files

0.1.2

2 release files

0.1.1

2 release files

0.1.0

2 release files

Anthropic, PBC Visionary sponsor Bloomberg Visionary sponsor Hudson River Trading Visionary sponsor Meta Visionary sponsor NVIDIA Visionary sponsor Microsoft Sustainability sponsor Depot Continuous Integration AWS Cloud computing and Security Sponsor Datadog Monitoring Fastly CDN Google Download Analytics Sentry Error logging StatusPage Status page