Skip to main content
Glama

control_run

Control Opentrons robot run execution with play, pause, stop, or resume actions for managing protocol workflows.

Instructions

Control run execution (play, pause, stop, resume)

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
robot_ipYesRobot IP address
run_idYesRun ID to control
actionYesAction to perform

Implementation Reference

  • The main handler function for the 'control_run' tool. It sends a POST request to the Opentrons robot's /runs/{run_id}/actions endpoint with the specified action (play, pause, stop, resume-from-recovery), fetches the updated run status, and returns a formatted response with success or error message.
    async controlRun(args) {
      const { robot_ip, run_id, action } = args;
      
      try {
        const body = {
          data: {
            actionType: action
          }
        };
        
        const data = await this.makeApiRequest(
          'POST',
          `http://${robot_ip}:31950/runs/${run_id}/actions`,
          { 'Content-Type': 'application/json' },
          JSON.stringify(body)
        );
        
        const actionData = data.data;
        
        // Get updated run status
        const runData = await this.makeApiRequest(
          'GET',
          `http://${robot_ip}:31950/runs/${run_id}`
        );
        
        const run = runData.data;
        
        return {
          content: [
            {
              type: "text",
              text: `✅ Run action '${action}' executed successfully!\n\n` +
                    `**Action ID:** ${actionData.id}\n` +
                    `**Run Status:** ${run.status}\n` +
                    `**Current Action:** ${run.actions?.[run.actions.length - 1]?.actionType || 'None'}\n` +
                    `**Completed At:** ${run.completedAt ? new Date(run.completedAt).toLocaleString() : 'Not completed'}\n`
            }
          ]
        };
      } catch (error) {
        return {
          content: [
            {
              type: "text",
              text: `❌ Failed to control run: ${error.message}`
            }
          ]
        };
      }
    }
  • Input schema definition for the 'control_run' tool, defining parameters: robot_ip (string), run_id (string), action (enum: play, pause, stop, resume-from-recovery). Included in the tools list returned by ListToolsRequestSchema.
      name: "control_run",
      description: "Control run execution (play, pause, stop, resume)",
      inputSchema: {
        type: "object",
        properties: {
          robot_ip: { type: "string", description: "Robot IP address" },
          run_id: { type: "string", description: "Run ID to control" },
          action: { type: "string", enum: ["play", "pause", "stop", "resume-from-recovery"], description: "Action to perform" }
        },
        required: ["robot_ip", "run_id", "action"]
      }
    },
  • index.js:256-257 (registration)
    Registration of the 'control_run' tool handler in the CallToolRequestSchema switch statement, dispatching calls to this.controlRun(args).
    case "control_run":
      return this.controlRun(args);
  • Helper method used by controlRun (and other tools) to make authenticated HTTP requests to the Opentrons robot API, handling Opentrons-Version header and common errors like connection refused.
    async makeApiRequest(method, url, headers = {}, body = null) {
      try {
        const options = {
          method,
          headers: {
            'Opentrons-Version': '*',
            ...headers
          }
        };
        
        if (body) {
          options.body = body;
        }
        
        const response = await fetch(url, options);
        const data = await response.json();
        
        if (!response.ok) {
          throw new Error(`API Error ${response.status}: ${data.message || JSON.stringify(data)}`);
        }
        
        return data;
      } catch (error) {
        if (error.code === 'ECONNREFUSED') {
          throw new Error(`Cannot connect to robot. Please check the IP address and ensure the robot is powered on.`);
        }
        throw error;
      }
    }
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries full burden but lacks behavioral details. It doesn't disclose whether actions are destructive (e.g., 'stop' might terminate a run irreversibly), authentication needs, rate limits, or response behavior. The description only lists actions without operational context.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, efficient sentence that front-loads the core purpose ('control run execution') and lists key actions. Every word earns its place with no redundancy or unnecessary elaboration.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a mutation tool with no annotations and no output schema, the description is incomplete. It lacks details on behavioral traits (e.g., what 'stop' does to the run), error scenarios, or return values. Given the complexity of controlling execution, more context is needed beyond the basic action list.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema fully documents parameters. The description adds no additional meaning beyond implying the action parameter controls execution states, which is already clear from the enum. Baseline score of 3 is appropriate as the schema handles parameter documentation.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb 'control' and the resource 'run execution', with specific actions listed (play, pause, stop, resume). It distinguishes from siblings like 'create_run' (creation vs. control) and 'get_runs' (retrieval vs. control), though it doesn't explicitly mention these distinctions.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is provided on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing an existing run from 'create_run'), exclusions, or contextual cues like error handling. The description only lists actions without usage context.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/yerbymatey/opentrons-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server