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, and a way to hand off long-running work so the device can run without the agent reasoning at every step.

MHP answers all three with one small protocol. It borrows the shape of the Model Context Protocol (MCP): JSON-RPC 2.0 messages, a short list of primitives, capability negotiation at connect time, and a host/client/server split. Where MCP exposes tools, resources and prompts, MHP exposes signals, settings, actions and a safety envelope, all described by one device descriptor that the driver serves and the agent reads before touching anything.

Design rules, in priority order:

1. Safety is enforced by the driver, never by the agent. Limits, interlocks and approval levels live in the descriptor and are checked on the device side of the wire. A wrong value from an agent is refused, not obeyed.
2. One descriptor is the whole manual. Everything an agent needs, including the tacit knowledge that used to live in paper manuals and people's heads, is written in natural-language notes fields on the descriptor.
3. Six primitives, no more. A device that speaks describe / signals / settings / actions / safety / methods can be operated by any MHP host.
4. Bridge, don't replace. OPC UA, ROS 2, SiLA 2, MADSci and PyLabRobot devices become MHP devices through thin adapters; MHP is the layer the agent sees.
5. The agent's context is a resource the protocol protects. A lab with two thousand devices costs the agent the same handful of tokens as a lab with two. Nothing is loaded that was not asked for (§3).