Starting work is deliberately split: upload_protocol puts the file on the robot, create_run starts a run against a protocol_id, and run_time_parameters can be supplied at either end. control_run is the single door for play, pause, stop and resume, so the run state machine stays in one place. poll_error_endpoint_and_fix changes your protocol rather than reporting on it, and it needs both the JSON error report and the original protocol path.
A server for Opentrons lab robots with a double role: a searchable index of the Opentrons HTTP API, and direct control of a robot addressed by robot_ip.
- API lookup: search_endpoints by functionality, method, path or keyword with an include_deprecated switch, get_endpoint_details for one method and path, list_by_category for a functional group, and get_api_overview for the structure as a whole.
- Protocols onto the robot: upload_protocol takes the file path, a protocol_kind and run_time_parameters, and get_protocols lists what the robot already holds.
- Run control: create_run against a protocol_id, control_run for play, pause, stop and resume, get_runs for the history and get_run_status for one run in detail.
- Robot state: robot_health for connectivity, control_lights, and home_robot for the axes or a specific pipette by mount.
- Error triage: poll_error_endpoint_and_fix fetches a named JSON error report and fixes the protocol it came from.
An Opentrons robot reachable over the network — the control tools take robot_ip — and the protocol file on disk, given as file_path to upload_protocol and as original_protocol_path to poll_error_endpoint_and_fix.
One command — npx -y opentrons-mcp