Open Model Hardware Protocol · open source
Let your AI agent run the lab.
OpenMHP is an open protocol that connects AI agents to lab instruments. It is an ordinary MCP server, so any harness can speak to it — but a tool call ends the moment it returns, and physical work does not. OpenMHP holds a lease on the instrument, runs the work as a job that outlives the conversation, and streams back what the device reports until it is done.
If you know MCP, you already understand most of OpenMHP. MCP gave AI applications one standard way to reach software tools and data. OpenMHP does the same for hardware: an instrument that speaks OpenMHP can be used by any agent, and an agent that speaks OpenMHP can use any instrument, without someone writing an integration for each pair. What it adds on top is everything a request-and-response call has no way to express — a lease, a job, a live event stream, and a safety gate no model can talk its way past.
MCP calls a tool. OpenMHP stays with the machine.
A software tool call is over when it returns. A thirty-cycle PCR runs for two hours, a plate arm is mid-move, an incubator has to be watched overnight. OpenMHP keeps the same MCP front door and adds the three things that gap needs: exclusive control while you have it, work that outlives the call, and a device that reports instead of waiting to be asked.
MCP
One call. When it returns, the agent has nothing holding the device and no way to hear what happens next.
OpenMHP
The work is a job with an id. The agent can close the session, come back tomorrow and ask how it went.
One session at a time holds the right to write and invoke, renewed by a heartbeat. It is also a dead man's switch: on an instrument that declares a watchdog, going quiet for longer than the window makes the device stop itself, cancel its jobs and latch safe rather than assume all is well. Reads, job status and emergency stop are never blocked by it.
Invoking an action returns a job id immediately, not a result. It moves through queued, running and then done, failed or cancelled, and can be paused, resumed or cancelled while it runs. A failed job reports an unknown outcome and holds the device in fault until someone verifies it, because a half-finished physical action is not a safe thing to guess about.
The device pushes. Signal changes, job progress and completion, safety events, faults and requests for a human all arrive as notifications, and the bridge records them against the run as they land. An agent reads what came in and decides what to do next. Nothing in that path polls the instrument.
Each device loads like an Agent Skill
The second idea OpenMHP borrows is from Agent Skills rather than MCP: an instrument is packaged like knowledge, not like an API. A device package is the instrument owner's knowledge, split into layers. The agent sees a tiny card while searching, opens the operating guide when it chooses the device, and loads exact specs or tested procedures only when the task needs them.
Agent context
The driver stays beside the hardware. Its safety rules are enforced on every call, whether or not they are in the agent's context.
From request to physical action
- 01“Run a 30-cycle PCR”The scientist states the outcome.
- 02FindSearch 2,000 lightweight device cards.
- 03UnderstandLoad this thermocycler's operating guide.
- 04SelectFetch only
run_protocoland its settings. - 05EnforceThe driver checks limits, interlocks and approval.
- 06RunThe instrument moves; progress streams back.
What you can do with it
Here is what a day with OpenMHP looks like for a scientist. None of it involves writing code.
- Ask for an experiment in plain words. "Run a 30-cycle PCR on the plate in A1 and hold it at 4 °C." The agent finds a thermocycler and a plate arm, reads the notes their owners wrote, picks a tested recipe, and runs it.
- See the plan before anything moves. The agent rehearses the whole procedure first and shows you every step, the points where it will stop and ask you, and anything the instrument would refuse. You say go.
- Ask an instrument which method to run. A GC or HPLC keeps its own methods per project and compound. The agent asks it, runs the one that matches, adjusts a parameter within limits if the result isn't good enough, and saves what worked as the next version — never invents parameters from nothing.
- Add a new instrument by answering questions. Say "onboard my hotplate". The agent asks about ten things a new colleague would ask: what is it, where is it, what can be set, what should never be set, how do you stop it. Then it writes the device description itself. Instruments you operate by hand, or that take text commands over a USB cable, need no programming at all.
- Leave it running overnight. A background run logs readings to a file and raises alerts. Every result the instrument produces is pushed to the run's own record as it happens — nothing is polled. In the morning you ask what happened, and the agent reads it back to you.
- Trust the limits. The temperature cap, the "lid must be closed" rule, the "a person confirms this" flag: all of it is written into the instrument's description by its owner and enforced by the driver on every call. An agent cannot talk its way past a limit. A watchdog stops the instrument on its own if the controlling process goes silent, and emergency stop is always allowed regardless of anything else happening.
- Keep the lab you have. Instruments already driven by OPC UA, ROS 2, SiLA 2, MADSci or PyLabRobot join with a few lines. Popular models have community packages with simulated twins, so you can try a procedure with nothing plugged in.
For people building agents or instruments, the same design gives you one integration for all hardware. The agent sees eleven tools whether the lab has two devices or two thousand, and its context stays small because devices load the way Agent Skills do: a short card in search results, the operating instructions when one is chosen, the full detail only when asked. In our test with 2,000 simulated devices, finding and opening the right one cost about 1,300 tokens. The full list is on the Features page.
Where to start
Why it matters, by role
- If you own an instrument, you describe it once, in your own words, and every agent uses it within the limits you set.
- If you build agents or harnesses, you integrate once. Every OpenMHP instrument works, and the tool list never grows.
- If you run experiments, you get an agent that plans before it acts, asks before anything you flagged, and can always be stopped.
Where OpenMHP came from
Anthropic solved the equivalent problem for software when it open-sourced the Model Context Protocol, and showed how to package procedural knowledge with Agent Skills. OpenMHP carries the same idea across to hardware: one open, shared way for any AI agent to connect to lab and factory instruments the way MCP connected agents to digital tools — and a small set of design principles that follow from it, like enforcing safety in the driver rather than trusting the agent, and treating an agent's context as a resource the protocol protects on purpose. The full reasoning, and what it means for a contribution, is on the Design principles page.
Common questions
Does it replace OPC UA, ROS 2 or SiLA 2? No. It sits on top of them. An adapter turns an OPC UA server, a ROS 2 node, a SiLA feature, a MADSci node or a PyLabRobot machine into an OpenMHP device in a few lines, and adds the safety envelope and the agent-facing description those layers do not carry.
Which AI model does it need? Any. OpenMHP is an ordinary MCP server, so the model is whatever your harness runs.
What stops an agent from doing something dangerous? The driver, not the agent. Limits, interlocks and approval levels are written into the device package by the owner and checked on the device side of the wire on every call. Changing a limit is a code review, not something an agent can do at run time.
Do I have to program to add my instrument? Usually not. The agent interviews you and writes the package. Hand-operated and USB-serial instruments need no code; instruments on the supported ecosystems need a few lines of bindings; only a vendor SDK or a binary protocol needs a short driver class.