plr-mcp
This MCP server lets any MCP client (e.g., Claude Desktop) control lab automation instruments via PyLabRobot — no direct coding required. It supports both simulation (chatterbox) and real hardware (Hamilton STAR, Opentrons OT-2, Tecan Freedom EVO).
Liquid Handler Setup & Deck Management
setup_deck— Initialize the liquid handler with a chosen backend, auto-load tip rack and 96-well platedeck_state— Inspect the current deck layout, loaded resources, and run mode
Liquid Handling Operations
pick_up_tips/drop_tips— Pick up or return tips using a well range (e.g.,A1,A1:H1)aspirate/dispense— Aspirate or dispense a specified volume (µL) from/to plate wellstransfer— Full transfer in one step: pick up tips → aspirate → dispense → drop tips
Plate Reader
read_plate— Read in absorbance (configurable wavelength), fluorescence (excitation/emission/focal height), or luminescence (focal height) mode
Thermocycler Control
thermocycler— Set block/lid temperature, open/close lid, deactivate, or check status
Heater-Shaker Control
heater_shaker— Set temperature, shake (with RPM and optional duration), stop, deactivate, or check status
All tools work end-to-end in simulation mode by default, requiring no physical hardware.
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., "@plr-mcp Setup the deck and transfer 100 µL from A1 to A2"
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.
plr-mcp
A Model Context Protocol server for PyLabRobot. It exposes a liquid handler, a plate reader, a thermocycler, and a heater-shaker as MCP tools, so any MCP client (Claude Desktop, Claude Code, or your own agent) can run lab-automation steps by calling tools instead of writing PyLabRobot code.
It ships in simulation mode by default. Every tool runs end to end against PyLabRobot's chatterbox backends with no instruments attached, so you can try the whole thing on a laptop. Point it at real hardware by setting one environment variable (see below).
Verified against PyLabRobot 0.2.1.
Why an MCP server (and not just tool-use)
Driving PyLabRobot from a Claude skill or direct tool-calls is tool-use inside one agent. An MCP server is a standalone process that speaks the Model Context Protocol over stdio, so any MCP client can discover and call these tools without knowing anything about PyLabRobot. This repo is the server.
Related MCP server: my-mcp-server
Install
git clone https://github.com/di-omics/plr-mcp.git
cd plr-mcp
pip install -e .This pulls in mcp and pylabrobot.
Prove it works (no hardware)
python examples/smoke_test.pyIt drives every tool through the chatterbox backends and prints ALL OK when
the run succeeds.
Run the server
plr-mcp # stdio transport, chatterbox simulation
PLR_MCP_BACKEND=star plr-mcp # target a real liquid handler insteadTools
Every tool is registered under a plr_ prefix so it stays unambiguous when this
server is loaded next to others.
Tool | What it does |
| Zero-motion hardware pre-flight: open the link to a real instrument, read its identity, close. Does not move the arm. See the hardware bring-up guide. |
| Build the liquid handler for the chosen backend and, for the liquid handler family, place a tip rack and a 96-well plate. Call this first. |
| List the resources on the deck and the run mode. |
| Pick up tips from the tip rack for a well range (for example |
| Return tips to the rack. |
| Aspirate a volume from each plate well in a range. |
| Dispense a volume into each plate well in a range. |
| One head pass: pick up, aspirate, dispense, drop. |
| Read absorbance, fluorescence, or luminescence. |
| Set block or lid temperature, open or close the lid, deactivate, status. |
| Set temperature, shake, stop, deactivate, status. |
| Generate a tool-agnostic, UMI-aware single-cell RNA-seq workflow with runtime-configured hooks for optional demultiplexing, UMI preprocessing, alignment, counting, and downstream analysis. Hook implementations are not bundled. |
| Run a validated PCR enrichment round 1 master-mix protocol by importing and executing the operator's existing starlab script (not a reimplementation). |
Well ranges use PyLabRobot syntax: a single well A1, a column A1:H1, or a
partial column A1:D1.
Tool semantics
Beyond names, the tools carry machine-readable metadata so an agent can use them safely:
Annotations. Each tool advertises MCP hints (
readOnlyHint,destructiveHint,idempotentHint,openWorldHint). Probes likeplr_connect_check,plr_deck_state, andplr_read_plateare read-only;plr_setup_deck(withhome), the liquid-handling tools,plr_thermocycler,plr_heater_shaker, andplr_run_pcr_enrichment_round1are marked destructive, so a client can warn before anything moves on real hardware.simulatedflag. Every result includessimulated.truemeans the numbers came from a chatterbox backend with no instrument attached; never read asimulated: truevalue as a real measurement.Structured output. Tools declare an output schema and return
structuredContent, so clients parse results against a named shape instead of an opaque object (requiresmcp>=1.9).Errors. Invalid arguments and unmet preconditions (unknown backend, bad well range, moving before
setup_deck/home) are raised as tool errors. Expected operational states a correct call can still hit (hardware unreachable from this host, missing vendor extra, a human-gated real run awaitingconfirm=true) come back as a normal result withok: falseand anoteslist to act on.
Connect a client
Claude Code
This repo ships a project-scoped .mcp.json, so just open the repo
in Claude Code and approve the plr server when prompted (check /mcp or
claude mcp list). It starts on the chatterbox backend, and Claude Code loads
CLAUDE.md for the tool catalog and safety rules. Tools appear
prefixed plr_ (for example plr_aspirate).
Prefer to register it yourself instead:
claude mcp add --transport stdio plr -- plr-mcpEither way, plr-mcp must be on PATH (pip install -e .); otherwise use the
absolute path from which plr-mcp, or -- python -m plr_mcp.server.
Claude Desktop
Add this to claude_desktop_config.json:
{
"mcpServers": {
"plr": {
"command": "plr-mcp"
}
}
}If plr-mcp is not on the client's PATH, use the absolute path to the console
script (which plr-mcp) or run it as python -m plr_mcp.server.
Backends
Pick the liquid-handling backend with PLR_MCP_BACKEND, or override it per
session in a setup_deck call (backend="star", etc.).
Backend | PyLabRobot backend | Deck | Runs with no hardware |
|
| STARLet | yes (default) |
|
| STARLet | no |
|
| OTDeck | no |
|
| EVO150 | no |
Only chatterbox runs with no instrument. The other three construct the real
PyLabRobot backend (correct API for 0.2.1) and attempt to connect; if no
instrument is reachable, or a vendor extra such as pylabrobot[opentrons] is
not installed, setup_deck reports that in notes instead of crashing. The
liquid handler tip and plate auto-load only for chatterbox and star; ot2 and
evo use vendor-specific labware, so load your own.
Driving a real STAR moves a physical arm. setup_deck(home=true) homes the
channels and iSWAP. The star backend defaults to a zero-motion connect and
blocks every liquid-handling tool until you home on a clear deck. Follow the
hardware bring-up guide for the first run.
For ot2, pass the robot IP:
PLR_MCP_BACKEND=ot2 PLR_MCP_OT2_HOST=169.254.1.1 plr-mcpThe non-liquid-handling instruments (plate reader, thermocycler, heater-shaker)
run on chatterbox simulation and expose real hardware backends as clearly
marked extension points in plr_mcp/lab.py (the _ensure_* methods). Wire in
your own (for example an Inheco ODTC thermocycler or a BioTek reader) and
validate on your deck before trusting a run.
Running a validated protocol
run_pcr_enrichment_round1 does not reimplement a protocol. It imports an existing,
hardware-validated starlab script and calls its own functions. Liquid parameters,
geometry, and tip logic remain operator-owned in that external run card; the MCP
wrapper does not bundle them and fails closed when the transfer contract is
incomplete. Point it at the scripts:
export PLR_MCP_STARLAB_DIR=/path/to/plr-tested/liquid-handler/starlab_liveOn a real run, follow the same ladder the scripts require: a clean
chatterbox dry-run, then mode='deck' on the instrument (assignment only),
then the transfer with a person watching. The star backend refuses to run
without confirm=true, because a real run homes the arm and moves liquid.
Layout
.mcp.json Claude Code project-scoped registration (starts on chatterbox)
CLAUDE.md guide Claude Code auto-loads (tools + safety rules)
plr_mcp/
lab.py stateful PyLabRobot wrapper (all the real calls live here)
server.py FastMCP server, one thin tool per Lab method
schemas.py TypedDict result shapes (the tools' output schemas)
protocols.py validated starlab protocol wrappers (run_pcr_enrichment_round1)
analysis.py single-cell RNA-seq pipeline generator
tests/
test_lab.py pytest suite, runs on chatterbox (no hardware)
examples/
smoke_test.py end-to-end run with no hardware
evals/
plr_mcp_eval.xml agent-usability questions answerable on chatterboxDevelopment
pip install -e '.[dev]'
ruff check plr_mcp tests # lint
ruff format --check plr_mcp tests
mypy plr_mcp --check-untyped-defs
pytest -qCI runs all four on Python 3.10 through 3.13 for every push and pull request.
License
MIT
Available Tools
10 toolsaspirateB
Aspirate volume microliters from each plate well in wells.
Inputs: wells (required), volume (required).
deck_stateA
List the resources currently assigned to the deck and the run mode.
Inputs: no named parameters.
dispenseB
Dispense volume microliters into each plate well in wells.
Inputs: wells (required), volume (required).
drop_tipsC
Return tips to the tip rack at the given range.
Inputs: wells.
heater_shakerA
Control the heater-shaker. action is one of: set_temperature (needs
temperature in Celsius), shake (needs speed in rpm, optional duration in
seconds), stop, deactivate, status.
Inputs: action (required), speed, duration, temperature.
pick_up_tipsA
Pick up tips from the tip rack. wells is a PyLabRobot range such as
'A1', 'A1:H1' (a full column), or 'A1:D1'.
Inputs: wells.
read_plateA
Read the plate in the reader. mode is 'absorbance' (uses wavelength),
'fluorescence' (uses excitation/emission/focal_height), or 'luminescence'
(uses focal_height).
Inputs: mode, emission, excitation, wavelength, +1 more.
setup_deckA
Initialize the liquid handler and place labware. Call this before any liquid handling tool.
backend: 'chatterbox' (simulation, no hardware), 'star' (Hamilton STAR), 'ot2' (Opentrons OT-2, needs host), or 'evo' (Tecan Freedom EVO). Defaults to the server's configured backend. For chatterbox and star a 1000 uL tip rack and a Corning 96-well plate are auto-loaded onto a STARLet deck. host: OT-2 robot IP address (only used when backend='ot2').
Inputs: host, backend, tip_rail, plate_rail.
thermocyclerA
Control the thermocycler. action is one of: set_block (needs
block_temp), set_lid (needs lid_temp), open_lid, close_lid, deactivate,
status. Temperatures are in Celsius.
Inputs: action (required), lid_temp, block_temp.
transferA
Transfer volume microliters from source wells to dest wells in one
head pass (pick up tips, aspirate, dispense, drop tips). Source and dest
ranges must have the same well count, at most one column.
Inputs: dest (required), source (required), volume (required), tips.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
Loading tool schema changelog…
TDQS
Scored across 10 tools
Each tool targets a distinct operation (aspirate, dispense, transfer, tip handling, deck setup, heater-shaker, thermocycler, plate reader) with no overlaps. Actions are clearly separated.
All tool names use lower_snake_case with clear verb_noun patterns (e.g., pick_up_tips, drop_tips, read_plate). Naming is uniform and predictable.
10 tools cover core liquid handling and lab equipment operations without being excessive. Each tool earns its place for a robotics lab server.
Covers setup, liquid transfers, tip management, temperature control, and reading. Minor gaps like explicit mixing or pause/move commands exist, but transfer can handle mixing.
Maintenance
Related MCP Connectors
MCP server for progressive tool usage at any scale (see https://klavis.ai)
QuLab MCP remote server (Streamable HTTP) for computational science and lab tools.
Model Context Protocol server for the Apideck Unified API. Connect any MCP-compatible agent framework to 100+ accounting systems, HRIS platforms, file storage providers, and more through one integration. More information https://www.apideck.com/mcp-server
Ovanek MCP: Model Context Protocol server for Ovanek platform tools; writes are dry-run by default.
Related MCP Servers
- AlicenseNot gradedqualityDmaintenanceA Model Context Protocol (MCP) server for seamless integration with peripheral devices connected to your computer. Control, monitor, and manage hardware devices through a unified API.5MIT
- FlicenseBqualityDmaintenanceA Model Context Protocol server built with FastMCP that enables dynamic tool loading and configuration from individual Python files. It provides a flexible framework for automatically discovering, testing, and running tools via Stdio or HTTP transport modes.1-
- AlicenseNot gradedqualityDmaintenanceModel Context Protocol server that standardizes tool discovery, execution, and context management for AI applications.MIT
- AlicenseAqualityDmaintenanceA simple Model Context Protocol server that provides a hello world greeting tool, serving as a boilerplate template for quickly creating new MCP servers.19 npmMIT