MHS vs. MCP: Anthropic's Two Standards, Explained

MHS vs. MCP: Anthropic's Two Standards, Explained

Anthropic's new Model Hardware Standard lets AI agents run lab robots and machines, while MCP connects models to software tools. Different layers, not rivals.

If you spent the past eighteen months wiring MCP into your stack, Anthropic's latest announcement reads like one more integration project landing on your roadmap. It isn't. The Model Hardware Standard (MHS) addresses a problem most software teams do not have — and it does not compete with the Model Context Protocol (MCP). It sits underneath it.

The distinction that matters: MCP connects AI models to information. MHS connects AI agents to machines.

What the Model Hardware Standard actually is

Anthropic opened a research preview of MHS on 27 August 2026. It is a shared specification — essentially a standardised driver layer — that lets AI agents discover and operate physical devices with a programmable interface: microscopes, liquid handlers, robotic arms, plate readers, centrifuges, even the laser systems that stabilise quantum computers.

The problem it attacks is integration cost. A laboratory instrument typically arrives with vendor-specific software, and making two instruments cooperate means writing bespoke glue code. Anthropic puts the typical effort at weeks to months; with MHS drivers, it claims hours to minutes.

The design is deliberately thin. A driver translates between the operating system and the hardware using two primitives — read and write — and advertises itself on the network in a common format. Anything a machine physically is, such as a robot arm's weight, gets captured as natural-language tags and compiled into a reference file listing capabilities, adjustable parameters and enforced safety limits.

That last part is the most interesting decision in the whole spec: safety limits live in the driver, not in the prompt. An instruction like “do not exceed this laser power” is enforced by the device layer, where a confused or manipulated model cannot argue with it. At Carnegie Mellon, testers deliberately injected six fault conditions; all six were blocked before anything moved.

The standard came out of a collaboration with HHMI's Janelia Research Campus, where a postdoc's shared-memory workaround for his imaging rig grew into a general spec. It is model-agnostic and remains gated behind an application process, with an open-source release still to come.

What MCP already does

MCP, launched in November 2024, solves the software version of the same fragmentation. Before it, every AI application needed a custom connector to every data source — an N-times-M integration problem that left models “trapped behind information silos.”

MCP replaced that with one open protocol. The result was unusually fast adoption for a vendor-originated standard: OpenAI adopted it in March 2025, Google DeepMind followed in April, and third-party trackers now catalogue roughly ten thousand public MCP servers. In December 2025 Anthropic donated it to the Agentic AI Foundation under the Linux Foundation — which is what turned it from an Anthropic product into neutral infrastructure.

Side by side

MCPMHS
ConnectsModels to data and software toolsAgents to physical devices
Stack layerContext and tool accessHardware driver layer
Maturity~2 years, vendor-neutralResearch preview, days old
GovernanceLinux Foundation (AAIF)Anthropic-controlled
Typical userAny AI application builderLabs, advanced manufacturing

Where the two actually meet

Here is the detail most coverage gets wrong, and the reason “MHS vs. MCP” is a false framing: MHS does not replace MCP — it exposes itself through it. Anthropic lists three ways to control an MHS device: the Model Context Protocol, a command-line interface, and ordinary code. An MCP server you already run can, in principle, front a robot arm.

So the relationship is layered, not competitive. An agent uses MCP to reach your warehouse system and your documents; when a step requires a physical action, that call resolves down into an MHS driver. MCP is the conversation. MHS is the hand.

The genuine overlap is narrow but real: both standards want to be the way an agent discovers capabilities it was not built for. If MHS succeeds, expect the boundary to blur — device actions become just another tool in the MCP catalogue, and the distinction stops mattering to application developers. That is arguably the point.

What to do with this

Most organisations should change nothing this quarter. MHS is a research preview aimed at scientific labs and advanced manufacturing, it requires an application, and it does not help you if your hardware has no programming interface.

If you operate physical equipment, three caveats deserve weight before any pilot. First, the headline results are Anthropic's own, not independently verified — Genentech, Carnegie Mellon, QuEra and the University of Washington all reported through the vendor. The numbers are striking: a QuEra laser-stabilisation routine succeeded on roughly 99% of blind trials against about 58% for the script it replaced, and held its lock for nineteen hours.

Second, the models are not ready to be left alone. In the Genentech trial, Claude repeatedly retried a failing pipetting step with small variations until a human explained that the viscous sample was foaming — a physical failure the model had no framework for. Anthropic says expert oversight remains required, and its own spatial-reasoning gaps are the stated reason.

Third, safety limits are only as good as their context. A speed limit that is safe for one robot arm configuration can become dangerous after a tooling change. Driver-level limits are a strong foundation, not a finished safety story.

For everyone else, the strategic read matters more than the technology. Both standards are model-agnostic by design — nothing here locks you to Claude. That is worth insisting on as you architect agent access: keep model routing neutral rather than embedding one vendor's client everywhere, so that a second vendor building on MHS later costs you a configuration change rather than a rebuild. If you access models through a gateway such as AKI.IO rather than a single vendor's SDK, that flexibility is already in place.

Outlook

MCP took roughly a year to move from Anthropic experiment to Linux Foundation stewardship. Expect MHS to move more cautiously: physical failure modes are irreversible in ways software failures are not, and Anthropic has paired the preview with safety evaluations and a promised physical-safety roadmap. Watch for two signals — the open-source release, and whether a second model vendor builds against the spec. Either would mark the shift from Anthropic project to standard.

What now?

Our practical perspective is: Treat MHS as a monitoring item, not a roadmap item, unless you run lab or manufacturing automation — in which case the application costs you little and the pilot data will be worth more than the announcement. Specific steps: inventory which of your devices expose a programmable interface, keep your MCP integration model clean enough that device tools could join it later, and read the safety guidance when it ships before you let anything near a moving part.

More articles