NIMO Controller: a self-driving laboratory orchestrator based on the Model Context Protocol

# NIMO Controller: a self-driving laboratory orchestrator based on the Model Context Protocol
Source: [https://arxiv.org/html/2605.15227](https://arxiv.org/html/2605.15227)
Naruki YoshikawaCorrespondence:yoshikawa\.naruki@nims\.go\.jpNational Institute for Materials Science, Tsukuba, Ibaraki, JapanRyo TamuraNational Institute for Materials Science, Tsukuba, Ibaraki, JapanGraduate School of Frontier Sciences, The University of Tokyo, Chiba, Japan

###### Abstract

Self\-driving laboratories \(SDLs\) have attracted increasing attention as a means of accelerating scientific discovery; however, developing SDL software remains technically demanding\. To improve accessibility, orchestration software frameworks have been proposed to coordinate SDL components\. Nevertheless, existing frameworks are primarily designed for human interaction and do not provide standardized interfaces suitable for AI agents\. In this work, we propose an SDL software architecture based on the Model Context Protocol \(MCP\), in which all SDL functionalities are exposed through MCP servers\. Following this design principle, we introduce an MCP\-based SDL orchestrator, named NIMO Controller\. It provides a visual programming interface automatically generated through MCP\-based tool discovery, allowing human users to design experimental workflows without writing code\. The same MCP backend can also be accessed by AI agents, providing a unified interface for both human users and AI agents\. We demonstrate the proposed system through a case study on a color\-matching SDL\. The results validate the usability of the proposed MCP\-based SDL architecture\.

## 1Introduction

Self\-driving laboratories \(SDLs\) combine robotic automated experiments with data\-driven experimental design to accelerate scientific discovery\[[11](https://arxiv.org/html/2605.15227#bib.bib1)\]\. Despite growing interest, the practical deployment of SDLs still faces several challenges\. Among these, software development presents an accessibility problem: most SDL software requires programming expertise, which limits adoption by domain experts who design experiments but do not write code\. To address this issue, various orchestration software frameworks have been proposed to support the development of SDL software\[[5](https://arxiv.org/html/2605.15227#bib.bib5),[7](https://arxiv.org/html/2605.15227#bib.bib7),[2](https://arxiv.org/html/2605.15227#bib.bib18)\]\. We have previously reported the integration of IvoryOS\[[13](https://arxiv.org/html/2605.15227#bib.bib9)\]and NIMO \(formerly NIMS\-OS\[[10](https://arxiv.org/html/2605.15227#bib.bib8)\]\), which provides a graphical user interface for laboratory workflow design that incorporates algorithmic decision\-making\[[12](https://arxiv.org/html/2605.15227#bib.bib2)\]\. Although IvoryOS automatically generates an accessible interface for human scientists from Python code, SDLs often require the integration of legacy devices that may not support Python\[[9](https://arxiv.org/html/2605.15227#bib.bib12)\]\. Furthermore, given the growing interest in AI scientists, SDL functionalities should also be accessible to AI systems\.

To enable interoperability between large language models \(LLMs\) and external tools, the Model Context Protocol \(MCP\) has recently been proposed\[[8](https://arxiv.org/html/2605.15227#bib.bib15)\]\. MCP standardizes the interface through which external tools and data sources are exposed to LLMs, making it a promising foundation for an SDL abstraction layer accessible to AI systems\. In this paper, we propose an MCP\-centric design for SDLs, in which both laboratory hardware and decision\-making algorithms are exposed as MCP tools\. Based on this design, we introduce a new SDL orchestrator, NIMO Controller\. A key feature of NIMO Controller is its ability to automatically generate a visual programming interface for human scientists by leveraging MCP\-based tool discovery\. The key contributions of this paper are as follows:

MCP\-based abstraction of SDL components: NIMO Controller adopts MCP to wrap each SDL component, including both laboratory hardware and decision\-making algorithms provided by NIMO, achieving loose coupling between the orchestration software and the underlying components\. Through this unified abstraction, both hardware operations and NIMO’s decision\-making algorithms become directly accessible via LLMs, allowing experiments to be controlled through natural language by either human users or AI agents\. The design also enables language\-agnostic development as well as plug\-and\-play extensibility, where adding a new device or algorithm requires only launching a new MCP server, without changing the client code\. Furthermore, remote experiments can be realized simply by adding remote MCP servers\.

Automatic generation of visual programming interface: To make SDLs accessible to users without programming expertise, NIMO Controller automatically generates a visual block\-based programming interface through the tool discovery functionality of MCP\. Users can visually design experimental workflows by composing draggable blocks, without writing code\. This lowers the entry barrier for domain experts and also supports the use of SDLs in student education\.

## 2System architecture

### 2\.1Overview

NIMO Controller acts as an MCP host that sits between users and MCP servers\. It provides a frontend interface that integrates both a visual programming interface and a natural language interface in a single application\. On the backend, NIMO Controller communicates with MCP servers to realize experiment planning and automated experimentation\. The architecture of NIMO Controller is shown in Figure[1](https://arxiv.org/html/2605.15227#S2.F1)\.

### 2\.2MCP servers

NIMO Controller orchestrates SDL components by communicating with MCP servers\. Two types of MCP servers are used: the NIMO MCP server exposes decision\-making algorithms, while component MCP servers expose the functionality of SDL components, such as laboratory hardware or external databases\.

#### 2\.2\.1NIMO MCP server

The NIMO MCP server is a dedicated MCP server that is always connected to NIMO Controller\. It wraps the NIMO library, which implements decision\-making algorithms for materials exploration\. The user first uploads a CSV file \(candidates\.csv\) that lists the candidate experimental conditions\. The MCP server then exposes the parameter names and their currently selected values, as well as thenimo\.selection\(\)tool, which proposes the next experimental conditions, and thenimo\.update\(\)tool, which updates NIMO’s internal state with the latest experimental results\. Visualization tools are also exposed; they return graphical representations of experimental results as images, which are displayed in the user interface\.

#### 2\.2\.2Component MCP servers

NIMO Controller can be connected to an arbitrary number of component MCP servers, each of which wraps a specific functionality relevant to the experimental workflow, such as laboratory robots or database services\. Any such functionality can thus be exposed to NIMO Controller as long as it is implemented in an MCP server\. Since the implementation of each MCP server is left to the developers, these components can be developed independently of the frontend, enabling the integration of legacy systems that do not support Python\. Furthermore, since MCP supports remote communication, component MCP servers can be hosted on remote machines, enabling remote experiments without any modification to NIMO Controller\. At the time of writing, component MCP servers have the following constraints\. Among the three primitives defined by MCP \(tools, resources, and prompts\), only tools are supported\. The output of MCP tools is displayed as texts or images\. For the visual programming interface, the input schema is limited to basic types supported by Blockly, such as numbers and strings\.

![Refer to caption](https://arxiv.org/html/2605.15227v1/x1.png)Figure 1:Architecture of NIMO Controller\. The controller serves as an MCP host that integrates a natural language interface \(via an LLM\) and a visual block\-based interface \(built on Blockly\) into a unified frontend\. Through MCP clients, these interfaces interact with backend MCP servers: a NIMO MCP server exposing decision\-making algorithms, and component MCP servers exposing laboratory hardware and other resources\.

### 2\.3User interface

NIMO Controller provides two types of user interfaces through which users interact with the MCP servers: a visual programming interface and a natural language interface\.

#### 2\.3\.1Visual programming interface

This interface uses Blockly to provide a drag\-and\-drop workflow editor\. Several types of block toolboxes are provided\. The core toolbox provides blocks for controlling the experimental workflow, such as repeat and conditional blocks\. The NIMO toolbox provides blocks for accessing NIMO’s decision\-making functionality, which is described in Section[2\.2\.1](https://arxiv.org/html/2605.15227#S2.SS2.SSS1)\. In addition, a dedicated toolbox is provided for each connected MCP server, containing blocks that execute the SDL functions exposed by that server\. These blocks are automatically generated from the tool definitions retrieved from the corresponding MCP server\. When the page is loaded, the frontend queries the capabilities of the MCP servers that were registered during the MCP initialization stage\. For each discovered tool, a Blockly block definition is dynamically generated, with input fields \(such as number or text fields\) derived from the tool’s input schema\. Users can then compose workflows by snapping blocks together\. When the user clicks the Run button, the designed workflow is sent to the backend and executed through calls to the corresponding MCP servers\. The interface highlights the currently executing block in real time\.

#### 2\.3\.2Natural language interface

Users can type natural\-language instructions into a chat interface\. The orchestrator forwards messages to an LLM agent that has access to the backend MCP servers\. The LLM agent is implemented using the OpenAI Agent SDK\. To guarantee safety, users are asked to approve or reject tool call requests from the agent\. Users can enable fully autonomous execution by turning on the auto\-approve toggle button, which activates automatic approval of tool calls\.

## 3Case study: Color\-matching SDL

To demonstrate NIMO Controller in a real\-world closed\-loop setting, we developed a color\-matching SDL as a proof\-of\-concept system\. Color matching has been used as an introductory problem in previous orchestration software\[[5](https://arxiv.org/html/2605.15227#bib.bib5)\]and in educational settings\[[1](https://arxiv.org/html/2605.15227#bib.bib16)\], making it a suitable testbed for evaluating NIMO Controller in a representative closed\-loop scenario\.

### 3\.1Experimental setup

The hardware of this SDL consists of a robotic arm \(DOBOT Magician\) equipped with an electronic pipette \(Picus 2, Sartorius\) and a UVC camera \(Shodensha\) for color measurement \(Figure[2](https://arxiv.org/html/2605.15227#S3.F2)\)\. Three food coloring dyes \(McCormick\) corresponding to the primary colors—red, yellow, and blue—are prepared in a 6\-well plate with 2 wells allocated per color, while a separate 12\-well plate is used as the mixing workspace\. A Petri dish filled with tap water is provided for washing the pipette tip between dispensing steps\. An MCP server wraps the SDL hardware and exposes functions for pipette control, robotic arm movement, and camera\-based color measurement, from which NIMO Controller automatically generates the corresponding Blockly blocks\.

![Refer to caption](https://arxiv.org/html/2605.15227v1/fig/setup_color_match.jpg)Figure 2:Hardware setup of the color\-matching SDL\.
### 3\.2Experimental procedure

The objective of this experiment is to find the mixture ratios of the three dyes that minimize the color difference between the mixed solution and a user\-specified target color\. The search space consists of the ratio of each color discretized into 20 levels from 0% to 100% in 5% increments, and the total dispensed volume is fixed at 2\.0 mL\. The color of the resulting mixture is captured by the camera and compared to the target color using the CIEDE2000 color difference formula\[[6](https://arxiv.org/html/2605.15227#bib.bib13)\], which provides a perceptually uniform measure of color dissimilarity\.

The experiment proceeds in a closed\-loop fashion using a 12\-well plate: the first four wells are used for random exploration to establish an initial dataset, and the remaining eight wells are used for optimization guided by PHYSBO\[[3](https://arxiv.org/html/2605.15227#bib.bib14),[4](https://arxiv.org/html/2605.15227#bib.bib17)\], a Bayesian optimization algorithm available in NIMO\. At each iteration, NIMO proposes a new set of dye ratios based on the previous observations, the robotic arm dispenses and mixes the dyes accordingly, and the camera measures the resulting color\. Since PHYSBO performs maximization by default, the negated value of the color difference is used as the optimization target\.

Users design the experimental workflow described above through the NIMO Controller visual programming interface\. The workflow consists of the following steps: \(1\) NIMO proposes the dye ratios for the next experiment; \(2\) the robotic arm dispenses and mixes the dyes in the specified amounts; \(3\) the camera captures the resulting color; \(4\) the color difference between the mixture and the target is computed; and \(5\) the result is fed back to NIMO to update its experiment history\. This workflow can be constructed without writing any code\. Figure[3](https://arxiv.org/html/2605.15227#S3.F3)shows a screenshot of NIMO Controller with the designed workflow and experiment logs\.

![Refer to caption](https://arxiv.org/html/2605.15227v1/fig/nimo_controller.jpg)Figure 3:A screenshot of NIMO Controller\. The left side shows the experimental workflow designed in Blockly, and the right side shows the log of the experiment with the output of each block\.
### 3\.3Results

We validated the system using two traditional Japanese colors as targets:*kikyou\-iro*\(bellflower purple; \#6A4C9C\) and*ama\-iro*\(flax beige; \#D6C6AF\)\. In both experiments, the optimization process exhibited a consistent improvement trend in the negated color difference over iterations \(Figure[4](https://arxiv.org/html/2605.15227#S3.F4)\), demonstrating that NIMO Controller successfully integrated perception, decision\-making, and hardware control into a closed loop\. The system autonomously navigated a three\-dimensional discrete parameter space and achieved progressively smaller perceptual color differences\. Each experimental iteration took approximately 12 minutes, dominated by robotic liquid handling\. These results confirm that NIMO Controller can orchestrate a multi\-step closed\-loop SDL workflow through a visual programming interface automatically generated from MCP servers\.

![Refer to caption](https://arxiv.org/html/2605.15227v1/fig/result1.jpg)\(a\)Photograph of the mix plate for experiment 1 \(target color:\#6A4C9C\)\.
![Refer to caption](https://arxiv.org/html/2605.15227v1/fig/result2.jpg)\(b\)Photograph of the mix plate for experiment 2 \(target color:\#D6C6AF\)\.
![Refer to caption](https://arxiv.org/html/2605.15227v1/fig/result1_graph.png)\(c\)Best negated color difference at each cycle of experiment 1\.
![Refer to caption](https://arxiv.org/html/2605.15227v1/fig/result2_graph.png)\(d\)Best negated color difference at each cycle of experiment 2\.

Figure 4:Results of the color\-matching SDL experiments\. Top row: photographs of the 12\-well plates after the experiments \(wells 1–4: random exploration; wells 5–12: Bayesian optimization\)\. Bottom row: best negated CIEDE2000 color difference achieved at each iteration, where higher values indicate a smaller perceptual color difference\. Both experiments show consistent improvement over iterations\.

## 4Conclusion and future perspectives

We have presented NIMO Controller, an MCP\-based SDL orchestrator that provides a no\-code interface to algorithmic decision\-making and automated experimentation through both a visual programming interface and a natural language interface\. We demonstrated the system through a color\-matching SDL case study, in which the complete closed\-loop pipeline was deployed without writing any client\-side code, validating both the accessibility and the plug\-and\-play extensibility of the proposed architecture\. Future work includes developing an intelligent AI agent capable of autonomously conducting experiments by invoking MCP tool functions, and conducting usability studies with students in educational settings\.

## Software availability

## Acknowledgments

This work was supported by JSPS KAKENHI Grant Number JP25K21333 and JST PREST Grant Number JPMJPR24T8\.

## References

- \[1\]\(2022\)What is a minimal working example for a self\-driving laboratory?\.Matter5\(12\),pp\. 4170–4178\.External Links:[Document](https://dx.doi.org/10.1016/j.matt.2022.11.007)Cited by:[§3](https://arxiv.org/html/2605.15227#S3.p1.1)\.
- \[2\]Y\. Fei, B\. Rendy, R\. Kumar, O\. Dartsi, H\. P\. Sahasrabuddhe, M\. J\. McDermott, Z\. Wang, N\. J\. Szymanski, L\. N\. Walters, D\. Milsted, Y\. Zeng, A\. Jain, and G\. Ceder\(2024\)AlabOS: a Python\-based reconfigurable workflow management framework for autonomous laboratories\.Digital Discovery3\(11\),pp\. 2275–2288\.External Links:[Document](https://dx.doi.org/10.1039/D4DD00129J)Cited by:[§1](https://arxiv.org/html/2605.15227#S1.p1.1)\.
- \[3\]Y\. Motoyama, R\. Tamura, K\. Yoshimi, K\. Terayama, T\. Ueno, and K\. Tsuda\(2022\)Bayesian optimization package: PHYSBO\.Computer Physics Communications278,pp\. 108405\.External Links:[Document](https://dx.doi.org/10.1016/j.cpc.2022.108405)Cited by:[§3\.2](https://arxiv.org/html/2605.15227#S3.SS2.p2.1)\.
- \[4\]Y\. Motoyama, K\. Yoshimi, T\. Aoyama, K\. Terayama, K\. Tsuda, and R\. Tamura\(2026\)Update of PHYSBO: improving usability and portability of bayesian optimization for physics and materials research\.arXiv preprint\.External Links:[Document](https://dx.doi.org/10.48550/arXiv.2603.01349)Cited by:[§3\.2](https://arxiv.org/html/2605.15227#S3.SS2.p2.1)\.
- \[5\]L\. M\. Roch, F\. Häse, C\. Kreisbeck, T\. Tamayo\-Mendoza, L\. P\. E\. Yunker, J\. E\. Hein, and A\. Aspuru\-Guzik\(2020\-04\)ChemOS: an orchestration software to democratize autonomous discovery\.PLOS ONE15\(4\),pp\. 1–18\.External Links:[Document](https://dx.doi.org/10.1371/journal.pone.0229862)Cited by:[§1](https://arxiv.org/html/2605.15227#S1.p1.1),[§3](https://arxiv.org/html/2605.15227#S3.p1.1)\.
- \[6\]G\. Sharma, W\. Wu, and E\. N\. Dalal\(2004\)The CIEDE2000 color\-difference formula: implementation notes, supplementary test data, and mathematical observations\.Color Research & Application30\(1\),pp\. 21–30\.External Links:[Document](https://dx.doi.org/10.1002/col.20070)Cited by:[§3\.2](https://arxiv.org/html/2605.15227#S3.SS2.p1.1)\.
- \[7\]M\. Sim, M\. G\. Vakili, F\. Strieth\-Kalthoff, H\. Hao, R\. J\. Hickman, S\. Miret, S\. Pablo\-García, and A\. Aspuru\-Guzik\(2024\)ChemOS 2\.0: an orchestration architecture for chemical self\-driving laboratories\.Matter7\(9\),pp\. 2959–2977\.External Links:[Document](https://dx.doi.org/10.1016/j.matt.2024.04.022)Cited by:[§1](https://arxiv.org/html/2605.15227#S1.p1.1)\.
- \[8\]\(2025\)Specification \- model context protocol\.Note:Accessed: May 9, 2026https://modelcontextprotocol\.io/specification/2025\-11\-25Cited by:[§1](https://arxiv.org/html/2605.15227#S1.p2.1)\.
- \[9\]R\. Tamura, H\. Taketa, S\. Murata, D\. Ryuno, T\. Yokota, K\. Tsuda, and S\. Matsuda\(2025\)Seamless integration of legacy robotic systems into a self\-driving laboratory via NIMO: a case study on liquid handler automation\.Science and Technology of Advanced Materials: Methods5\(1\),pp\. 2565144\.External Links:[Document](https://dx.doi.org/10.1080/27660400.2025.2565144)Cited by:[§1](https://arxiv.org/html/2605.15227#S1.p1.1)\.
- \[10\]R\. Tamura, K\. Tsuda, and S\. Matsuda\(2023\)NIMS\-OS: an automation software to implement a closed loop between artificial intelligence and robotic experiments in materials science\.Science and Technology of Advanced Materials: Methods3\(1\),pp\. 2232297\.External Links:[Document](https://dx.doi.org/10.1080/27660400.2023.2232297)Cited by:[§1](https://arxiv.org/html/2605.15227#S1.p1.1)\.
- \[11\]G\. Tom, S\. P\. Schmid, S\. G\. Baird, Y\. Cao, K\. Darvish, H\. Hao, S\. Lo, S\. Pablo\-García, E\. M\. Rajaonson, M\. Skreta, N\. Yoshikawa, S\. Corapi, G\. D\. Akkoc, F\. Strieth\-Kalthoff, M\. Seifrid, and A\. Aspuru\-Guzik\(2024\)Self\-driving laboratories for chemistry and materials science\.Chemical Reviews124\(16\),pp\. 9633–9732\.External Links:[Document](https://dx.doi.org/10.1021/acs.chemrev.4c00055)Cited by:[§1](https://arxiv.org/html/2605.15227#S1.p1.1)\.
- \[12\]N\. Yoshikawa, T\. Ozawa, W\. Zhang, J\. Hein, R\. Tamura, and M\. Shoichi\(2026\)Bridging decision\-making engines and workflow design in self\-driving laboratories: a NIMO–IvoryOS integration study\.ChemRxiv\.External Links:[Document](https://dx.doi.org/10.26434/chemrxiv.15000670/v1)Cited by:[§1](https://arxiv.org/html/2605.15227#S1.p1.1)\.
- \[13\]W\. Zhang, L\. Hao, V\. Lai, R\. Corkery, J\. Jessiman, J\. Zhang, J\. Liu, Y\. Sato, M\. Politi, M\. E\. Reish, R\. Greenwood, N\. Depner, J\. Min, R\. El\-khawaldeh, P\. Prieto, E\. Trushina, and J\. E\. Hein\(2025\)IvoryOS: an interoperable web interface for orchestrating Python\-based self\-driving laboratories\.Nature Communications16\(1\),pp\. 5182\.External Links:[Document](https://dx.doi.org/10.1038/s41467-025-60514-w)Cited by:[§1](https://arxiv.org/html/2605.15227#S1.p1.1)\.