On August 27, Anthropic announced the research preview of the Model Hardware Standard (MHS) — a model-agnostic protocol that lets AI agents discover and operate physical equipment: lab instruments, manufacturing tools, robotics. Early partners include Genentech (drug-discovery experiments with real-time error handling) and HHMI Janelia Research Campus (an imaging pipeline compressed from weeks to a day).

I’ve spent the last year wiring MCP servers into internal tools — ticket systems, deploy pipelines, internal dashboards. When I read the MHS spec, my first reaction was: this is MCP’s shape, transplanted onto hardware. My second reaction, as someone who has been paged at 2am because a tool call did something irreversible to a database, was: what happens when the “irreversible” thing is a centrifuge?

The shape is familiar

MHS follows a pattern every MCP integrator will recognize: a discovery layer, a capability schema, and a call/response loop with structured errors. Roughly:

{
  "device": "centrifuge-04",
  "capabilities": [
    {
      "name": "run_spin_cycle",
      "params": { "rpm": "int", "duration_s": "int", "temp_c": "float" },
      "safety_envelope": { "rpm_max": 15000, "duration_max_s": 3600 },
      "requires_ack": true
    }
  ],
  "state": "idle"
}

Compare that to a typical MCP tool definition for, say, a deploy pipeline:

{
  "name": "trigger_deploy",
  "inputSchema": { "environment": "string", "commit_sha": "string" },
  "annotations": { "destructiveHint": true, "idempotentHint": false }
}

Same skeleton — declared capability, typed params, a hint about blast radius. MHS just adds a safety_envelope field and a hardware-specific state machine. If you’ve built guardrails around MCP tool calls (approval gates for destructiveHint: true, dry-run modes, rate limits), you already have the mental model for MHS. The difference is that your rollback story for a bad deploy is git revert. There is no git revert for a ruined reagent batch or a scorched sample.

What changes when the tool call is physical

Three things stood out reading the spec and Anthropic’s writeup, all of which map onto lessons I’ve already learned the hard way with software agents:

1. Idempotency stops being a nice-to-have. In software, a retried API call is usually safe if you designed for idempotency keys. A retried run_spin_cycle call is not idempotent by nature — the sample already spun once. MHS pushes this responsibility onto the safety envelope and requires_ack, but the agent’s retry logic has to know the difference between “the network dropped and nothing happened” and “the network dropped after the centrifuge already started.” That’s a much harder failure classification problem than a typical HTTP 5xx.

2. Error handling needs physical semantics, not HTTP semantics. A 429 means “try again later.” What does a hardware equivalent of 429 mean when the device is mid-cycle? Genentech’s case study specifically calls out “real-time error handling” — which tells me the interesting engineering work here isn’t the happy path, it’s the exception taxonomy: transient sensor fault vs. mechanical fault vs. safety-envelope violation vs. operator intervention required. If MHS doesn’t nail that taxonomy, every integrator will reinvent it badly, the same way early REST APIs each had their own ad hoc error shapes before problem-details (RFC 7807) standardized it.

3. The blast radius argument for open standards gets stronger, not weaker. Anthropic is explicitly positioning MHS as model-agnostic and planning to open-source it. That’s the right call, and it’s the same argument that made MCP itself succeed over vendor-proprietary tool-calling formats: a lab that adopts MHS isn’t locking itself into Claude. But open, widely-adopted standards for physical control also mean the attack surface for prompt injection or tool-poisoning attacks — already a known MCP risk class — now extends to equipment that can cause physical harm. I’d want a hardware MHS deployment gated behind the same kind of allowlisting and signed-capability-manifest scrutiny we’re starting to apply to MCP servers in supply-chain-conscious shops.

Where I’d actually use this

I don’t run wet labs, but the pattern generalizes past biotech. Any Tech Lead running physical infrastructure — a robotics test rig, a hardware-in-the-loop CI setup, even a datacenter with agent-operated PDUs — should be watching this space, because MHS is trying to become the MCP-equivalent standard for “agent talks to a thing that isn’t a web API.” If it gets adopted the way MCP did, the winning move is the same: don’t build a bespoke integration layer per device vendor, wait for (or contribute to) the standard, and spend your engineering time on the safety envelope and approval-gating logic instead — because that’s the part no standard can fully solve for you.

The honest caveat: this is a research preview with a handful of design partners, not a GA spec. MCP took roughly a year from announcement to being the de facto standard everyone assumed by default. MHS could follow the same curve, or it could stay a niche lab-automation format if the open-source release slips or the safety story doesn’t hold up under broader adoption. Worth tracking, not worth re-architecting anything around yet.

Sources: Anthropic: Previewing the Model Hardware Standard, CNBC coverage

Export for reading

Comments