Model Hardware Standard: Anthropic's MCP for the physical world

Anthropic put Model Hardware Standard into research preview on August 27 and 28, and the shortest accurate description is MCP for the physical world. MHS is a standardized driver that sits between an operating system and a physical device, robot arms, microscopes, liquid handlers, and exposes the device through simple read and write commands. The driver also carries the device's physical characteristics: its mass, its safety limits, the parameters that can be adjusted, information that used to live in a manual or in one technician's head. The standard is model-agnostic, available for now to selected organizations in science, robotics and manufacturing, with open-sourcing planned.

What MHS actually standardizes

If you know how MCP works, the shape is familiar. A tool describes itself, a model discovers the description, the model calls the tool with structured arguments, the tool returns a structured result. MHS applies the same pattern to hardware, with two differences that matter.

First, the primitive is read and write, not arbitrary function calls. A microscope stage exposes a position you can read and a target you can write. The narrowness is deliberate: a small vocabulary is easier to reason about and easier to constrain.

Second, the self-description includes physics. An MCP tool tells the model what arguments it takes. An MHS driver tells the model that the arm weighs this much, that this joint must not exceed this angle, that this parameter is adjustable within this range. The safety envelope is data the model receives before it acts, not a guardrail bolted on after.

Why the safety-metadata layer is the whole point

Every tool-calling system I have built for software has one property MHS cannot have: a bad call is usually reversible. A robot arm that moves 30 centimeters too far does not have an undo. A liquid handler that dispenses into the wrong well has consumed a sample.

That is why the physical characteristics in the driver are the important part, not the read/write API. The model needs the limits in its context before it decides, and the driver needs to enforce them regardless of what the model decides. Both, not either. Anthropic's own framing is honest about this: real-world action safety is a harder problem than software tools, and a closed preview is the right stage for it.

Tool calling for software can afford a bad call; tool calling for hardware has to make the bad call impossible before the model ever sees the tool.

Google is pushing from the model side. Gemini Robotics 2, noted in mid-August, ships three variants (VLA, ER 2 and On-Device 2) with full-body autonomy and new safety layers. The two approaches are complementary: Google is training the policy, Anthropic is standardizing the socket the policy plugs into.

If you are building toward this

• Treat every write as irreversible in your design review. Ask what happens if the model writes the maximum allowed value, then the minimum, then both in quick succession.
• Put the limits in two places. In the driver description the model reads, and in the driver code that refuses out-of-range writes. Never trust the model to respect the description.
• Log reads and writes with the model's stated intent. After a failure you want what the model thought it was doing, not just what it sent.
• Rate-limit physical actions. A software tool can be called a thousand times a second. A stage motor cannot, and a runaway loop is a mechanical failure, not a cost overrun.
• Reuse your validation layer. The output validation pattern applies directly: parse the model's command into a typed structure, validate against the envelope, then execute.
• Keep a human on the first N runs. Not a checkbox; a person with a stop button watching the physical device.

The honest gap

MHS is a research preview for selected organizations, with no public specification I have been able to read. The description above is Anthropic's description of the concept, via its announcement and coverage in CNBC and the Japan Times, not a review of a protocol document. Open-sourcing is planned, not dated. Until the spec is public, everything here is the shape of the idea, and the details that decide whether it is safe in practice, how limits are enforced, how drivers are authenticated, what happens on a lost connection mid-write, are exactly the details nobody outside the preview has seen.