You cannot build on the Model Hardware Standard today. That is not a complaint, it is the published state of things: MHS is a gated research preview, access is by application, and as of 29 August 2026 there is no public specification, schema, SDK or repository. If you want to connect AI to hardware this month, you need something else.
The good news is that five well-documented options already exist, several of them free and open, all of them with real users you can go and verify. This is a builder’s decision tree for choosing among them — useful whether or not MHS ever ships, and worth reading first even if you intend to adopt MHS later, because whichever of these you pick will still be underneath it.
First, Be Precise About What Is Missing
It is worth separating what Anthropic has described from what a developer could implement, because the gap is the entire reason this article exists:
| Described — Anthropic says this exists | Specified — you could build against it |
|---|---|
A driver concept, read/write primitives, tags, a reference file | A published schema for the reference file — not public |
| Three access paths: MCP, a CLI, and code files/APIs | A command syntax, SDK methods or API reference for any of them — not public |
| “Discoverable in a standard format” | An actual discovery protocol — not public |
| Safety limits that “will be enforced” | Where enforcement happens, and the trust model for a tag — not public |
| Open-sourcing is stated as future intent | A public repository — none as of this writing |
The left column is real and interesting. The right column is what you would need, and none of it is available. The landing page functions as an application form, not a documentation site.
So: five things that are documented.
1. Wrap What You Have in an MCP Server
Best for: getting an agent talking to a device you already control programmatically, fastest.
Almost every serious instrument already exposes something — a vendor SDK, a REST API, a serial or VISA command set, a ROS 2 driver. If you can drive it from a script today, you can put an agent in front of it today.
The Model Context Protocol is public, documented and widely implemented, and writing an MCP server that exposes a handful of tools — get_temperature, set_temperature, home_stage — is an afternoon’s work for someone who already has the device scripted. That gets you most of what “an agent that can read and write a device” means in practice.
Worth being clear about what this does not give you: cross-vendor discoverability, and an auto-generated safety reference file. Those are the two genuinely novel pieces of MHS’s design, and neither falls out of wrapping your own device.
The design warning, which matters more here than anywhere else in this article: an MCP tool that accepts a free-form string has moved the decision into text a model composes. Constrain the parameters — enumerate the operations, bound the numeric ranges in the tool schema, and enforce the real limits in the layer underneath. An agent should not be able to request 200 mW because it reasoned its way there.
2. SiLA 2 — If You Are in a Lab
Best for: laboratory instruments, cross-vendor, with a real standard behind it.
SiLA — Standardization in Laboratory Automation — is a consortium whose stated mission is “free and open systems communication and data standards” for lab instruments. The SiLA 2 specification is documented publicly and developed in the open.
The part that matters architecturally: Feature Definitions. A SiLA server describes its own capabilities in a machine-parseable, versioned document, so a client can ask “what can you do?” and get a structured answer rather than a PDF. The standard’s own site describes the flow in almost conversational terms — the client searches for servers, the server answers “Yes, I am here!”, and Feature Discovery reports what it can do.
If your problem is lab instruments from multiple vendors, this is the standard aimed squarely at you, and it exists now.
3. OPC UA — If You Are in Industry, or Need Trust Built In
Best for: industrial equipment, and any case where authentication cannot be an afterthought.
OPC UA is the heavyweight, and the only option here that treats trust as part of discovery rather than a bolt-on: X.509 certificate exchange is part of the connection handshake, and its Global Discovery Server role includes certificate lifecycle management.
Capability description runs through companion specifications — governed, versioned information models for particular domains. There is also a lab-facing effort, LADS (OPC UA for Laboratory and Analytical Devices), a joint working group of the OPC Foundation, SPECTARIS and VDMA aiming at “a manufacturer-independent, open standard for analytical and laboratory equipment.”
The trade-off is weight. Companion specs are slow because they are governed, and the licensing status of full specification text is worth checking before you plan around it — treat “free to read about, may require membership for the full text” as the honest position.
4. ROS 2 — If It Moves
Best for: robot arms, mobile platforms, anything with kinematics.
If your hardware is a robot rather than an instrument, ROS 2 is the default and has been for years. Discovery, typed message interfaces, and a very large ecosystem of existing drivers mean that for a lot of commercial arms, someone has already written the integration.
The specific piece worth knowing about is ros2_control, the standard hardware-abstraction framework — it is the layer that lets the same motion code drive different hardware.
Two cautions. Security is opt-in: DDS-Security and SROS2 are not on by default, so an untouched ROS 2 graph will believe anything that can multicast on its domain. And ROS 2’s own discovery design article is explicit that it “does not aim to answer all implementation questions or suggest implementation strategies” — the shipped behaviour comes from DDS, not from that document.
5. SCPI over VISA — If It Is on a Bench
Best for: oscilloscopes, power supplies, signal generators, spectrum analysers.
The oldest option, and still the right one for test-and-measurement gear. SCPI is a text command language sitting on IEEE-488.2, described by the IVI Foundation as “a pure software standard” usable over GPIB, RS-232, VXIbus or LAN. VISA gives you one addressing grammar across GPIB, USB (USBTMC) and LAN (VXI-11 or HiSLIP).
Send *IDN? and nearly any compliant instrument replies with manufacturer, model, serial and firmware. That one command validates your entire stack in a single round trip.
Its limitation is the one MHS is aiming at: there is no machine-readable description of an instrument’s command set. That lives in the PDF programming manual, and a human reads it.
(An honourable mention that is not on this list because it is proprietary and commercial: LabVIEW. Worth knowing that National Instruments is now a business segment inside Emerson following an acquisition that closed in October 2023, if you are making a long-horizon platform decision.)
Choosing
| Your hardware | Start here | Why |
|---|---|---|
| Already scriptable, want an agent on it | MCP server | Fastest path, uses what you have |
| Lab instruments, multiple vendors | SiLA 2 | Purpose-built, versioned Feature Definitions |
| Industrial equipment, or trust is critical | OPC UA | Only option with certificates in the handshake |
| Robot arms, mobile platforms | ROS 2 | Ecosystem and existing drivers |
| Bench test-and-measurement | SCPI / VISA | Universal, trivial to start, huge installed base |
| Low-cost robot arm, learning-focused | LeRobot | Open, active, hardware you can actually buy |
These are not mutually exclusive, and the most common real architecture is layered: SCPI or ROS 2 talking to the hardware, an MCP server exposing a constrained set of operations to the agent, and the actual limits enforced somewhere neither of them can argue with.
The Part That Does Not Change
Whichever route you take, one design decision outlives all of them.
The agent-facing layer is a convenience layer. It decides what gets requested. It should not be the thing that decides what is possible. Put the real limits where the model cannot reach them — in a credential that lacks the permission, in a tool schema that cannot express the dangerous value, in firmware, in an interlock. Then the choice between MCP, SiLA, OPC UA, ROS 2 and SCPI becomes what it should be: an integration decision, not a safety one.
That is also the most useful thing to have in place before MHS opens up. When a driver arrives carrying natural-language tags describing your instrument’s limits, the question you will want to have already answered is what happens if one of those tags is wrong.
Frequently Asked Questions
Can I build against the Model Hardware Standard right now?
No. MHS is a gated research preview with access by application, and as of 29 August 2026 there is no public specification, schema, SDK or repository. Anthropic has described a driver concept, read/write primitives, natural-language tags and an auto-generated reference file, and has said it intends to open-source the standard — but none of the material a developer would need to implement a driver is published.
What is the fastest way to let an AI agent control a device I already have?
Wrap its existing interface in an MCP server. If you can drive the device from a script today — through a vendor SDK, a REST API, a VISA command set or a ROS 2 driver — exposing a few constrained tools to an agent is typically an afternoon’s work. Constrain the tool parameters rather than accepting free-form strings, and enforce the real limits in the layer underneath.
Which standard should I use for laboratory instruments?
SiLA 2 if you want a lab-specific open standard with versioned, machine-parseable Feature Definitions, and it is documented publicly today. OPC UA if you need certificate-based trust built into the connection handshake or you are bridging to industrial equipment — its LADS working group targets analytical and laboratory devices specifically. SiLA 2 is lighter; OPC UA is heavier and more institutionally mature.
Is ROS 2 secure by default?
No. DDS-Security and the SROS2 layer are opt-in, so a ROS 2 graph running with default settings will accept topic announcements from anything that can multicast on its domain. That is a reasonable default for a lab bench on an isolated network and a poor one for anything reachable from a wider network. Enable it deliberately rather than assuming it.
Will learning these be wasted effort if MHS takes off?
No, for a structural reason: something still has to put bytes on the wire. MHS describes a standardised driver and an agent-facing abstraction, not a replacement for the transport and command layers underneath it — and Anthropic’s own material names MCP as one of three access paths into MHS. The installed base of SCPI instruments, ROS 2 robots and OPC UA equipment does not disappear because a new abstraction arrives above it.
📦 Recommended Resources
Every standard in this article is documented free and publicly — SiLA’s specification is developed in the open, the OPC Foundation publishes its reference browser, ROS 2’s documentation is extensive, MCP’s spec is public, and your instrument’s programming manual is a free download from its vendor. Start there; none of these books teach you a command syntax. They teach the judgement that makes the integration decision a good one.
- AI Agents in Action by Micheal Lanham — the most directly applicable book for route 1. Wrapping a device in an MCP server is the easy part; deciding what tools to expose, how to constrain their parameters, and how to structure an agent’s interaction with a stateful external system is where projects go wrong. Read it with this article’s closing warning in mind: the tool schema is a design surface, not a formality. (A second edition exists; the ISBN above is the one we verified.)
- Modern Robotics: Mechanics, Planning, and Control by Kevin M. Lynch and Frank C. Park — essential if route 4 is yours. ROS 2 gives you the plumbing and assumes you know the robotics; this is the book that supplies the second part, from configuration spaces through trajectory generation. The authors make it legitimately available free from their companion site, so read before you buy.
- Functional Safety: A Straightforward Guide to Applying IEC 61508 and Related Standards by David J. Smith and Kenneth G. L. Simpson — the book behind this article’s last section. “Put the real limits where the model cannot reach them” is a slogan until you can assess whether a given protective arrangement actually holds, and this is the text that turns it into something you can specify and check. The rung most engineers building agent integrations have never climbed. (2nd edition, 2004; a later retitled edition exists but the ISBN above is the verified one.)
✅ Pro tip: Whichever route you pick, write the “what if this value is wrong” answer down before you write the integration. If the honest answer is “the agent would command something harmful and nothing would stop it,” you have found your next task — and it is not in the agent layer.