Discover laboratory capabilities, submit tasks, and interpret execution feedback through a shared interface.
简体中文 · Quick start · Client integration · Device integration · Documentation
Technical report: Read PDF · Download PDF
SCP-Lab extends the Science Context Protocol (SCP) for autonomous laboratories. Scientific agents discover experimental capabilities and submit tasks through a shared interface; facility backends control devices or integrated workstations and return execution status and experimental results. Agents use this feedback to refine subsequent experimental plans.
The scientific agent, SCP-Lab, and facility backend have distinct responsibilities:
| Role | Responsibility |
|---|---|
| Scientific agent | Develop experimental plans, discover facility capabilities and initiate tasks, analyze feedback, and refine subsequent experiments |
| SCP-Lab | Unify device and capability registration and discovery, standardize capability descriptions and control scope, and provide interfaces for task submission, status, results, and completion evidence |
| Facility execution backend | Check requests and local execution conditions, control devices or integrated workstations to carry out experimental operations, and return execution status, results, and completion evidence |
flowchart LR
Agent["Scientific agent"] -->|Experimental task| SCP["SCP-Lab"]
SCP -->|Task request| Backend["Facility execution backend"]
Backend -->|Status, results, and completion evidence| SCP
SCP -->|Execution feedback| Agent
When registering a device, integrators specify its capabilities, including supported operations, parameters, and completion criteria, and associate an execution backend. Agents discover and inspect these capabilities through SCP-Lab to understand which operations a facility can perform and which parameters they can adjust. They use this information to select suitable facilities, design experiments, and submit tasks. During execution, the backend returns status, results, and completion evidence through SCP-Lab so the agent can evaluate the findings and refine subsequent plans.
SCP-Lab uses five access levels, L1–L5, to describe the control a facility exposes, from complete workflows to actuator actions. This helps agents choose between reusing established procedures and organizing finer operations according to experimental needs, while giving facilities with different control granularity a consistent way to integrate. Integrators can choose task granularity and orchestration arrangements accordingly.
SCP-Lab provides an MCP-compatible interface so existing MCP clients can access facility capabilities. See the design guide for details of access levels, execution feedback, and MCP compatibility.
Have Git and uv available, then run:
git clone https://github.com/InternRobotics/SCP-Lab.git scp-lab
cd scp-lab
uv sync --frozen --python 3.12 --extra mcpThis installs SCP-Lab and its MCP dependencies in .venv. If you already have the source, run only the last command from the repository root. See the installation guide for environment setup, verification, and troubleshooting.
After installation, choose a tutorial or go directly to an integration guide.
| Tutorial | What you will explore |
|---|---|
| Introduction: your first device call | Discover a demonstration device, submit a task, and understand execution feedback |
| Advanced: OT-2 simulation | Generate code from a pipetting request, run it in the official simulator, and inspect the result |
| Your goal | Guide | What you will build |
|---|---|---|
| Call devices from an application or agent | Application integration | An MCP connection that discovers capabilities, submits requests, and reads outcomes |
| Register device instances | Device configuration | One saved configuration per instance, using an existing adapter |
| Wrap an SDK or laboratory service | Backend development | A reusable adapter that provides capability definitions and returns execution feedback |
| Content | Purpose |
|---|---|
| Device-access API over local MCP stdio | Discovery, capability inspection, submission, polling, state queries, and cancellation where supported |
| Offline interface catalog | Request validation for 45 device models and 89 action definitions |
| OT-2 backend | Code generation and official simulation, with a separately installed simulator |
| Mock devices and adapter template | Examples for client integration, execution lifecycle, and multiple device instances |
The model definitions are independent files organized by device family. Their instance configurations make them callable through MCP; the same files provide examples for publishing a new device interface.
Bundled backends run in software. Connecting physical equipment requires a hardware adapter.
- User guide: tutorials, integration instructions, and reference pages.
- Examples: device calls, multi-device sequences, lifecycle handling, and custom backends.
- Protocol reference and JSON Schemas: messages, units, defaults, lifecycle, and evidence.
- Contributing: development setup and checks.