Is MHS a replacement for ROS 2?

No. ROS 2 is a robotics middleware — it handles real-time messaging, control loops, sensor fusion and motion planning between processes on and around a robot. MHS is a description layer that tells an AI agent what a device can do and what its safety limits are. A realistic stack runs MHS above ROS 2, with ROS 2 executing the motion and MHS describing what motions are legal to request.

What is the difference between MCP and MHS?

MCP connects models to software resources — APIs, files, databases and apps. MHS, announced August 27 2026, connects models to physical devices such as robot arms, microscopes and liquid handlers. The structural difference is that an MHS specification carries a safety envelope, for example maximum speed or permitted angles, because the failure mode is physical rather than a bad API response.

Which should I adopt in 2026?

MCP today, since it is stable, widely adopted and where most agent integration value sits. ROS 2 if you are actually building robots and need deterministic control. MHS only if you build or operate lab, robotics or manufacturing hardware and can join the research-preview waitlist — it is not generally available and has no open-source date.

Can an agent control hardware with MCP alone?

Technically yes, by wrapping device commands in MCP tools, and many teams already do. The gap is that MCP has no native concept of a physical safety envelope, so limits live in your prompt or your wrapper code — both weak places for a constraint that must hold. MHS exists precisely to move that limit into the device's own machine-readable specification.

Quick Answer

MHS vs MCP vs ROS 2: AI Hardware Control Compared

Published: August 28, 2026

The Short Answer

These are three layers of one stack, not three competing options:

Agent reasoning        ← Claude, GPT, Gemini
  ↓  MCP               ← software: APIs, files, apps
  ↓  MHS               ← device description + safety envelope
  ↓  ROS 2 / firmware  ← real-time control, motion, sensors
Physical machine

Teams get this wrong by asking “should we use MHS or ROS 2.” The right question is which layer your problem lives in.

The Comparison

	MCP	MHS	ROS 2
Owner	Anthropic (open, widely adopted)	Anthropic	Open Robotics / OSRA
Announced	Nov 2024	Aug 27, 2026	2017 (ROS since 2007)
Status	Stable, industry standard	Research preview, waitlist	Mature, production
Connects models to	software and data	physical devices	nothing — it is the device layer
Real-time guarantees	none	none	✅ DDS-based, real-time capable
Safety envelope	❌ prompt or wrapper code	✅ declared by the device	✅ in controller code
Discovery	tool listing	capability + measurement listing	topic/service introspection
Open source	✅	intended, no timeline	✅ Apache 2.0
Use it for	agent ↔ apps	agent ↔ instruments	robot internals

Where Each One Belongs

MCP — the software layer

MCP is the mature choice and the one almost every agent team should already be using. It standardises how a model reaches tools, files and APIs, and its adoption extends well past Claude to other assistants.

Its limit for hardware is structural, not incidental. You can absolutely wrap move_arm(x, y, z) in an MCP tool and many teams have. But MCP has no first-class notion of “this arm must never exceed 0.5 m/s.” That constraint ends up in a system prompt, or in your wrapper’s validation code, or in a comment. All three are places a constraint can quietly stop holding.

MHS — the device description layer

MHS adds exactly the missing piece: the device itself declares its capabilities, its measurements, its adjustable settings and its safety limits, in a form an agent can read without a PDF manual or a resident expert.

Anthropic’s framing is direct — “What MCP did for software, MHS will do for the hardware world.” The example given at announcement is a robot arm vendor specifying safe manipulation by limiting speed or angles, so the vendor who understands the machine owns the constraint rather than the integrator who does not.

What MHS is not: a control system. It does not run a control loop, it does not do motion planning, and it offers no real-time guarantee. It tells an agent what is possible and permitted. Something else does the moving.

ROS 2 — the control layer

ROS 2 is where the actual robotics happens: node-to-node messaging over DDS, deterministic timing, sensor fusion, kinematics, planning, hardware drivers. It has a decade-plus of production deployment behind it.

ROS 2 is not going anywhere and MHS does not threaten it. If anything, MHS makes ROS 2 systems more valuable by giving agents a safe, standardised way to ask them for things.

A Realistic 2026 Stack

For a lab automation scenario:

Layer	Component	Responsibility
Reasoning	Claude / other agent	interpret the experiment, sequence steps
Software tools	MCP	LIMS, protocol database, notebook, storage
Device access	MHS	discover instruments, read limits, issue operations
Execution	vendor firmware / ROS 2	actually move, heat, pipette, image
Verification	MHS measurements → MCP	write results back to the record

The Genentech demonstration Anthropic showed follows exactly this shape: a scientist sends Claude a PDF of a designed experiment, and the assistant executes it on MHS-equipped hardware. The PDF arrives through the software layer. The execution happens through the hardware layer. Neither substitutes for the other.

What to Adopt, and When

Adopt MCP now. It is stable, broadly supported, and the majority of practical agent capability still lives in software. If your agent stack does not use it yet, that is the gap worth closing this quarter.

Adopt ROS 2 if you build robots. Nothing about MHS changes this calculus. Real-time control is a solved problem with a mature answer.

Watch MHS, and join the waitlist if you are in scope. As of August 28, 2026 it is a research preview limited to selected scientific, robotics and manufacturing organisations. Anthropic intends to open-source it after the preview, with safety evaluations and deployment guidance, but has declined to commit to a timeline. Early partners include AWS, Danaher, Hugging Face and Raspberry Pi.

Copy the idea immediately even if you cannot use the standard. The transferable lesson is that a physical safety limit belongs in a machine-readable specification owned by whoever built the machine — not in a prompt, and not in integration glue. You can implement that pattern today with your own schema and be ready when the standard opens.