Specification · section 1
Why MHP
Every instrument on a bench or factory floor has its own programming interface. Connecting them to each other is hard. Connecting them to an AI agent is harder, because the agent needs three things no vendor API provides:
- a uniform way to read and write the device;
- a machine-readable account of what the device is and how to use it safely;
- a way to hand off long-running work so the device runs without the agent reasoning at every step.
MHP answers all three with one small protocol that borrows the shape of MCP: JSON-RPC 2.0 messages, a short list of primitives, capability negotiation at connect time, and a host, client, server split.
| MCP exposes | MHP exposes |
|---|---|
| tools | actions, which return jobs the device runs on its own |
| resources | signals to read and settings to write |
| prompts | a device package: card, operating instructions, references |
| (nothing) | a safety envelope: limits, interlocks, approval levels, e-stop, enforced by the driver |
Design rules, in priority order
- Safety is enforced by the driver, never by the agent. A wrong value from an agent is refused, not obeyed.
- The device package is the whole manual. Tacit knowledge from paper manuals and people's heads is written down where the agent reads it.
- Five primitives, no more. Describe, signals, settings, actions, safety.
- Bridge, don't replace. SiLA 2, PyLabRobot, MADSci, OPC UA and ROS 2 devices join through thin adapters.
- The agent's context is protected. Two thousand devices cost the same handful of tokens as two (§3).