The single hardest sentence in Anthropic’s Model Hardware Standard announcement is also the one that sounds easiest. MHS drivers, it says, make devices “discoverable in a standard format, so that devices and agents can find each other and communicate across networks without needing a bespoke ‘translator’ program.”
That is the entire public description of the discovery mechanism, as of 29 August 2026. It states a goal, and goals are the easy part. Every system that has actually shipped device discovery has discovered the same thing on the way: “find each other” is not one problem. It is five, and they come apart.
The Five Sub-Problems
Any discovery mechanism, in any era, has to answer all of these:
- Identity — what uniquely names this device?
- Capability description — what can it do, in a format software can act on?
- Addressing — how do you actually reach it once you have found it?
- Versioning — how does a change to the device or its interface get communicated?
- Trust — why should the thing that answered “I’m here” be believed?
The fifth is the one that takes years. The first four are engineering; trust is politics, cryptography and institutional design, and most systems below shipped without it and bolted it on later — or never.
Measured against those five, MHS’s public material currently answers one in operational detail: capability description, via the auto-generated reference file. Anthropic has not published a discovery protocol, a namespace model, an addressing scheme, a versioning scheme, or a trust model for the discovery step. That is not a criticism of a research preview — it is a map of what remains to be specified, and the six systems below show what specifying it has cost everyone else.
1. ROS 2, over DDS: Identity and Capability, Bundled
ROS 2’s shipped discovery runs on DDS, where participants announce themselves and negotiate matching publishers and subscribers by topic name plus a typed message definition. The elegant part is that identity and capability arrive together: a node does not merely announce “I am a camera,” it announces that it publishes sensor_msgs/Image on /camera/image. Another node either speaks that type or it does not.
Addressing is handled by domain-scoped multicast discovery converging to unicast endpoints. Versioning is informal — it lives in the interface package’s own version, not in a protocol field.
Trust is not in the default path at all. DDS-Security, and ROS 2’s SROS2 layer, are opt-in. A ROS 2 graph that never enables them is, by design, a network where anyone who can multicast on the domain can announce a topic and be believed.
Worth noting that ROS 2’s own design article on discovery is candid about its scope: it “explores the ideal and theoretical aspects of discovery and negotiation. It does not aim to answer all implementation questions or suggest implementation strategies.” Even the people designing it treated the document as a statement of intent.
2. OPC UA: The Only One That Treats Trust as Part of Discovery
OPC UA is the heavyweight, and the most institutionally complete answer to all five sub-problems.
Part 12 of the specification, “Discovery and Global Services,” formally defines a Local Discovery Server — a per-host registry of servers on that machine — and a Global Discovery Server for enterprise-scale registration and certificate management. That second role is what sets OPC UA apart: certificate lifecycle management is part of the discovery architecture, not an add-on. X.509 certificate exchange is baked into the connection handshake itself.
Capability description runs through companion specifications — governed, versioned information models published by the OPC Foundation for specific domains, including robotics and machine vision. So “what can this device do” is answered by a schema with a standards body behind it rather than by free text.
That is the most mature answer available. It is also the slowest and heaviest one: companion specs take a standards body and years. Which is precisely the friction that an agent-authored, natural-language-sourced reference file is implicitly betting it can shortcut.
3. SiLA 2: The Lab-Instrument Answer
SiLA 2 aims at exactly the domain MHS is entering — laboratory instruments — and describes its own discovery flow in almost conversational terms on the standard’s site: “The LIMS searches for SiLA Servers,” and the “Server answers Yes, I am here!”
For capability description, “SiLA Feature Discovery allows a SiLA Client to find out what Features a SiLA Server” has: the client asks “What can you do?” and the server “explains what capabilities (Features) it possesses.”
The important structural detail is that SiLA 2’s Feature Definitions are per-capability, machine-parseable and versioned — the same shape of answer OPC UA gives through companion specs, at a lighter weight aimed specifically at lab work. (Descriptions of the underlying transport as gRPC/Protobuf with an XML Feature Definition Language are plausible and consistent with SiLA 2’s public architecture, but were not independently confirmed against the specification documents for this article — treat that detail as needing a check before you rely on it.)
4. mDNS and DNS-SD: Ubiquitous, and Trustless in the Literal Sense
This is the one already running on your home network. RFC 6762, published February 2013 by Stuart Cheshire and Marc Krochmal of Apple, defines Multicast DNS over UDP port 5353, using multicast addresses 224.0.0.251 for IPv4 and FF02::FB for IPv6, so devices can resolve .local names “with less configured infrastructure” — no central server. Paired with DNS-SD (RFC 6763), capability description rides in TXT records: small, informal key-value hints attached to a service advertisement, not a schema.
Every printer, Chromecast and AirPlay speaker you have ever connected to used this. It is the most widely deployed answer to identity and addressing in existence.
It is also the plainest illustration of the trust gap: mDNS has no authentication at all. Any device on the local link that answers a query is believed. For a printer, that is an understood and accepted trade-off. For a device with a laser attached, it is a materially different trade-off — and it is the clearest reason why “discoverable across networks” is a sentence that needs a trust model attached before it means anything safe.
5. USB Enumeration: Trust by Physical Proximity
USB solves discovery without any network step at all. A device identifies itself at connection time through a VID:PID pair — a vendor ID administered by the USB Implementers Forum, plus a product ID the vendor assigns — and a descriptor tree of device, configuration, interface and endpoint descriptors that together are the capability description, read automatically by the host at enumeration.
The trust model is physical: if it is plugged in, the OS believes what its descriptors claim.
That assumption is now well understood to be insufficient. The BadUSB class of attacks exploits exactly it — a device that lies about its own descriptor class, presenting as a keyboard when it is not. The relevance to MHS is direct and worth stating carefully: a device that can misdescribe its own capabilities to the software controlling it is not a new problem MHS introduces. It is an old problem, and a natural-language authoring step is a new and less formal way to reproduce it.
6. SCPI over VISA: Forty Years of the Gap MHS Wants to Close
The oldest system here is also the sharpest contrast.
VISA — Virtual Instrument Software Architecture, maintained by the IVI Foundation — standardises addressing across GPIB, USB (via USBTMC) and LAN (via VXI-11 or HiSLIP) through a resource string in a fixed, transport-specific grammar. SCPI — Standard Commands for Programmable Instruments — layers a common command syntax on top, and nearly every SCPI instrument answers a *IDN? query with manufacturer, model, serial number and firmware revision as a plain string.
That is a minimal, universal answer to identity and versioning that predates everything else in this article by decades, and it still works on benches today.
What SCPI and VISA never solved: there is no standard machine-readable capability schema. What a given instrument’s full command set actually is remains something you learn from its PDF manual, not from the instrument itself.
That is precisely the gap Anthropic’s case studies describe the MHS reference file as closing. The comparison worth sitting with: SCPI/VISA left it unsolved for forty years, in a domain with hard real-time and safety requirements — and MHS proposes to close it with natural language that a person, or an interviewing agent, typed once.
The Scorecard
| System | Identity | Capability | Addressing | Versioning | Trust |
|---|---|---|---|---|---|
| ROS 2 / DDS | Topic + typed msg | Typed message defs | Multicast → unicast | Informal (package) | Opt-in only |
| OPC UA | Server certificate | Companion specs | LDS / GDS registry | Governed schemas | Built into handshake |
| SiLA 2 | Server identity | Feature Definitions | Server discovery | Versioned features | Partial |
| mDNS / DNS-SD | .local name | TXT records (hints) | Multicast DNS | None | None |
| USB | VID:PID | Descriptor tree | Bus enumeration | Device release field | Physical proximity |
| SCPI / VISA | *IDN? string | None (PDF manual) | Resource string | Firmware in *IDN? | Transport-level |
| MHS (public info) | Not specified | Reference file | Not specified | Not specified | Not specified |
Read the bottom row as a research preview’s honest state, not a verdict. Every other row took years — and in OPC UA’s case, a standards body — to fill in.
What This Predicts
Three things follow from the pattern, and they are worth watching for as MHS moves toward the open-source release Anthropic has said it intends.
Trust will be the hard one, and it will arrive late. Four of the six systems above shipped without it. Only OPC UA treated it as part of discovery from the start, and OPC UA is the heaviest system in the comparison — that is not a coincidence, it is the price.
Free-text capability descriptions and governed schemas are a real trade, not a strict improvement. OPC UA companion specs and SiLA Feature Definitions are slow because they are governed; a natural-language tag is fast because nobody has to agree with it. Speed is a genuine advantage right up until two implementations disagree about what a word meant, and there is no schema to arbitrate.
A self-described device is a trust assumption in every system here. USB learned it painfully. mDNS never pretended otherwise. The reference file inherits the same property: it says what the driver’s author asserted, which is not automatically what the hardware does.
None of this makes MHS’s discovery ambition wrong. It makes it normal — the same five problems, in the same order, with the same one left for last. The useful question for anyone evaluating it is not whether devices can find each other, but which of the five it has answered this month, and whether the fifth is being designed in or deferred.
Frequently Asked Questions
What does “device discovery” actually have to solve?
Five separable sub-problems: identity (what uniquely names this device), capability description (what it can do, in a machine-actionable format), addressing (how to reach it), versioning (how interface changes are communicated), and trust (why the responder should be believed). Systems routinely ship having solved the first four and defer the fifth, which is why trust is the sub-problem that distinguishes a mature discovery architecture from a working one.
How much of discovery has MHS publicly specified?
One of the five, in operational detail: capability description, through the auto-generated reference file. As of 29 August 2026 the public material states the goal — devices and agents “can find each other and communicate across networks” — without publishing a discovery protocol, namespace model, addressing scheme, versioning scheme or trust model. MHS is a gated research preview with no public specification, so this reflects what has been described, not necessarily what exists.
Which existing system handles discovery trust best?
OPC UA, by a clear margin, because it is the only one in this comparison that treats trust as part of discovery rather than an add-on. X.509 certificate exchange is built into the connection handshake, and its Global Discovery Server role explicitly covers certificate lifecycle management. The cost is weight: OPC UA’s governed companion specifications require a standards body and years of work.
Why does mDNS matter to a conversation about lab instruments?
Because it is the clearest demonstration of what “discoverable on a network” means without authentication. mDNS has no built-in authentication — any device on the local link that answers a query is believed. That is a sensible trade-off for a printer and a very different one for an instrument with an actuator or a laser, which is why a discovery claim should always be read together with its trust model.
What is the strongest historical parallel for the MHS reference file?
SCPI over VISA, because it is the same domain and the opposite outcome. SCPI instruments have answered *IDN? with manufacturer, model, serial and firmware for decades, but there has never been a standard machine-readable description of an instrument’s full command set — you read the PDF manual. That is exactly the gap the reference file aims at, left open for forty years in a field with hard real-time and safety requirements.
📦 Recommended Resources
Almost everything cited in this article is free and primary: RFC 6762 and RFC 6763 are readable in an afternoon, the OPC Foundation publishes its reference browser openly, SiLA’s standards site describes its own discovery flow in plain language, and the ROS 2 design articles are public. Read those first — they cost nothing and they are the actual sources. These books are for the layer underneath: how you reason about systems that have to find, describe and trust each other.
- Modern Robotics: Mechanics, Planning, and Control by Kevin M. Lynch and Frank C. Park — the standard text for the domain ROS 2 exists to serve, and the one that makes the typed-message model make sense: once you understand configuration spaces, kinematics and trajectory planning, “publishes
sensor_msgs/Imageon/camera/image” stops looking like plumbing and starts looking like an interface contract. Worth knowing that the authors make the book legitimately available free from the companion site as well, so you can read before you buy.
- Engineering a Safer World: Systems Thinking Applied to Safety by Nancy G. Leveson — relevant here for the trust column of the scorecard. Leveson’s argument is that safety comes from constraints enforced on system behaviour, which is exactly the lens that separates OPC UA’s built-in certificate handshake from mDNS’s cheerful willingness to believe anyone on the local link. If you want to reason about why the fifth sub-problem is categorically harder than the other four, this is the framework.
- Laboratory Automation in the Chemical Industries edited by David G. Cork and Tohru Sugawara — the oldest and most expensive item we recommend anywhere, and included honestly on that basis: it is the book-length treatment of the instrument-integration problem that SiLA and OPC UA LADS are still working on. Worth it only if lab automation is your actual field; if you are here for the networking argument, the first two books serve you better. (Verified against bibliographic record; Amazon’s own listing has been intermittently unreachable.)
✅ Pro tip: If you only read one primary source from this article, make it RFC 6762. It is the clearest worked example of a discovery protocol that deliberately chose zero configuration over any authentication — and understanding why that was the right call for printers is the fastest way to see why it is the wrong call for actuators.