Opentrons MCP Server
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Server capabilities have not been inspected yet.
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| search_endpointsC | Search Opentrons HTTP API endpoints by functionality, method, path, or any keyword |
| get_endpoint_detailsC | Get comprehensive details about a specific API endpoint |
| list_by_categoryC | List all endpoints in a specific functional category |
| get_api_overviewB | Get high-level overview of the Opentrons HTTP API structure and capabilities |
| upload_protocolC | Upload a protocol file to an Opentrons robot |
| get_protocolsC | List all protocols stored on the robot |
| create_runC | Create a new protocol run on the robot |
| control_runC | Control run execution (play, pause, stop, resume) |
| get_runsB | List all runs on the robot |
| get_run_statusC | Get detailed status of a specific run |
| robot_healthC | Check robot health and connectivity |
| control_lightsC | Turn robot lights on or off |
| home_robotC | Home robot axes or specific pipette |
| poll_error_endpoint_and_fixC | Fetch specific JSON error report and automatically fix protocols |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 14 tools
Most tools have distinct purposes, but there is some overlap between get_endpoint_details, list_by_category, and search_endpoints, which all relate to API endpoint discovery and could cause confusion. Additionally, poll_error_endpoint_and_fix combines error fetching and fixing in one tool, which might overlap with general run control functions.
The naming follows a consistent verb_noun pattern (e.g., control_lights, create_run, get_protocols) with only minor deviations like poll_error_endpoint_and_fix being more descriptive and robot_health as a noun phrase. Overall, it's readable and mostly predictable.
With 14 tools, this is well-scoped for managing an Opentrons robot, covering protocol handling, run control, robot operations, and API exploration. Each tool appears to serve a specific function without being excessive.
The tool set covers core robot operations (lights, homing, health), protocol lifecycle (upload, list, create runs), and run management (control, status). A minor gap is the lack of a tool for deleting or modifying protocols, but agents can likely work around this.