Model Hardware Standard (MHS)
Learn how MHS connects AI agents with physical hardware through inspectable interfaces and explicit safety boundaries.
Last updated: 2026-08-29
What MHS is
The Model Hardware Standard (MHS) is a research direction for giving AI agents a shared way to discover, inspect, and operate physical devices. It is not a robot model and it is not a promise that an agent can safely control every device without supervision.
Anthropic describes MHS as a shared specification for AI agents to operate physical devices. Its early examples include lab automation, microscopy, quantum hardware, and scientific workflows. The common idea is an explicit interface between an agent, device state, tools, and the actions that can change the physical world.
Why this site starts with a directory
Smithery demonstrates a useful product pattern for agent infrastructure: discover a resource, inspect its capabilities and setup, then connect it in the runtime where it will be used. Robot MHS applies that pattern to physical systems, with more attention to provenance, simulation, permissions, telemetry, and stop behavior.
The first release therefore ships a small open directory before it ships a hosted marketplace. Each entry records:
- the canonical project or specification;
- current status and license;
- transport or adapter shape;
- capabilities that can be inspected;
- a link to the contribution and review context.
What the research tells us
Anthropic's robotics evaluation shows why an interface matters: perception, state understanding, planning, and low-level control are separate problems, and tools can bridge some of the gap. Recursive self-improvement research also makes evaluation and oversight important. Better models do not remove the need for explicit boundaries around actions, feedback, and human control.
Scope and safety
Robot MHS is an independent community project. It is not affiliated with Anthropic and does not define or certify the MHS research preview. Do not connect an unreviewed adapter to a real robot. Start in simulation, expose read-only state first, add dry-run planning, and require an explicit stop path before enabling physical actions.