Model Hardware Standard for Lab Automation: MHS, MCP, and SiLA 2

The Model Hardware Standard (MHS) is Anthropic's research-preview approach for letting AI agents discover, operate, and monitor programmable physical equipment through standardized drivers. For laboratory automation, MHS is best understood as a hardware abstraction that can work through MCP - not as a replacement for MCP, SiLA 2, OPC UA LADS, or the deterministic safety controls between an AI plan and a physical instrument.

That distinction matters because a common interface can make hardware easier to reach without making every action safe to execute. The public MHS material is an important signal for instrument vendors, but the specification is not open yet and the published demonstrations remain early evidence rather than a production or regulatory assurance.

Key Takeaways

• MHS targets the agent-to-hardware integration layer. Its public description combines standardized drivers, device discovery, state, procedures, safety context, and several access mechanisms.
• MCP and MHS solve different problems. MCP gives an AI application a standard way to call tools; MHS describes how programmable physical equipment can sit behind those tools.
• SiLA 2 and OPC UA LADS are not made obsolete. They already provide laboratory-specific device contracts and information models that an MHS driver may be able to consume or expose.
• Safety cannot live in a natural-language description alone. Preconditions, limits, interlocks, operation identity, authorization, and recovery behavior must remain deterministic.
• Instrument vendors can prepare now without betting on an unpublished specification. A typed, observable, testable device interface will be useful whether the eventual integration uses MHS, MCP, SiLA 2, OPC UA LADS, or more than one of them.

What Anthropic Has Actually Announced

Anthropic opened the MHS research preview on August 27, 2026. The project began with HHMI Janelia Research Campus and is being tested with scientific laboratories and hardware manufacturers before a planned open-source release.

The public description gives MHS five important responsibilities:

1. A standardized driver translates between a device and the surrounding software.
2. Devices become discoverable in a common format.
3. The driver exposes state and operations through simple primitives and a device manifest.
4. Device knowledge can include characteristics, operating context, and limits that are not obvious from code alone.
5. Agents can access the hardware through MCP, a command-line interface, or code.

The announcement describes proof-of-concept workflows spanning liquid handlers, robotic arms, plate readers, qPCR instruments, microscopes, cameras, and other programmable equipment. It also reports cases where agents monitored experiments, adjusted parameters, coordinated devices, and recovered from selected faults.

Those results are worth studying, but they need the correct label: they are reports from Anthropic and its preview partners. They are not yet evidence of broad interoperability, conformance across independent implementations, validated operation in regulated environments, or safe autonomy for arbitrary hardware.

Anthropic makes the limitation explicit. Its announcement says current models still have weaknesses in spatial and physical reasoning, require expert oversight, and can misdiagnose physical problems as software problems. The preview is intended partly to develop the missing safety evaluations and deployment guidance.

Where MHS Fits in a Laboratory Automation Stack

The easiest way to understand MHS is to separate the layers that are often collapsed into the word "integration."

The diagram shows one plausible composition based on the public MHS description. MCP is the agent-facing interaction protocol. MHS is the hardware-facing abstraction and driver model. A laboratory device contract such as SiLA 2, OPC UA LADS, a vendor SDK, or a REST API can provide the underlying capabilities. Deterministic verification, authorization, and state reconciliation remain on the execution path before any physical actuation.

This composition is an engineering interpretation, not an MHS conformance claim. Until a public specification defines the contracts and extension points, nobody outside the preview can state exactly how an MHS implementation must map onto an existing laboratory standard.

Layer	Primary responsibility	What it does not guarantee
MCP	Lets an AI application discover and call tools through a standard protocol	Safe physical behavior, device semantics, or successful execution
MHS	Describes a common driver and discovery model for programmable physical equipment	Broad interoperability or production readiness while the specification is not yet published
SiLA 2	Defines laboratory device Features, typed Commands, Properties, discovery, and error behavior	Agent-level intent or a complete semantic safety model for every workflow
OPC UA LADS	Models laboratory hardware, functions, programs, state, and result management	A universal natural-language interface or automatic agent safety
Vendor API or SDK	Provides the native path to a particular instrument	Cross-vendor portability or a consistent tool surface

The MCP tool specification defines how servers expose callable tools and their schemas. It does not claim that a schema can determine whether a liquid handler has enough reagent, whether a plate is sealed, or whether a timed-out command already moved an axis. Those are physical-state questions.

SiLA 2 addresses a lower, laboratory-specific contract. Features expose typed commands and properties, while the core standard covers discovery, errors, data types, security, and observable execution. OPC UA LADS goes further into a laboratory information model, separating hardware and functional views and defining programs, functional units, state, and result management.

MHS may become a useful common layer over these interfaces. It may also influence how future instruments expose them. The important architectural point is that these technologies occupy different layers, so "MHS vs MCP" or "MHS vs SiLA 2" is usually the wrong procurement question. The better question is: which contract owns each piece of meaning, state, safety, and execution evidence?

The Standardized Driver Is Necessary, but It Is Not the Safety Boundary

An AI agent can produce a syntactically valid command that is physically wrong. transfer_liquid(source="A1", destination="B1", volume_ul=100) may match its schema while the source contains 40 uL, the destination is already full, or the mounted tip has contacted an incompatible reagent.

The driver should reject such a command before actuation, but that requires more than an operation name and a parameter type. It requires current state, cross-parameter rules, equipment limits, and workflow context.

Five controls therefore need to stay deterministic below the agent:

1. Preconditions and state-dependent limits

Static ranges catch obvious errors, such as a negative temperature or an unsupported speed. Real workflows also need dynamic checks: available volume, mounted tooling, occupied positions, calibration state, door state, consumable identity, and whether another operation owns the device.

The agent can propose the action. Software with access to authoritative state decides whether the preconditions are satisfied.

2. Durable operation identity

A network timeout does not mean the instrument did nothing. The command may have been rejected, accepted but not started, completed without an acknowledgement, or left partially complete.

Every consequential operation needs a durable identifier and lifecycle. Repeating the same identifier should retrieve the existing operation or be rejected as a conflict, not silently aspirate a second time. This is why observable instrument commands matter more than a synchronous success response.

3. Executable verification before dispatch

Parameter validation checks one call. A useful protocol often contains dozens of dependent operations across several instruments. The complete candidate workflow should be evaluated against resources, ordering constraints, and expected state transitions before execution.

A digital twin dry run is one way to implement that boundary. It does not need photorealistic rendering. It needs enough state to prove that the proposed sequence is executable and to return a specific refusal when it is not.

4. Authorization proportional to consequence

Reading a temperature and starting a robot are not equivalent operations. The system needs explicit authority boundaries for observation, configuration, maintenance, motion, and sample-affecting actions. High-consequence plans may also require a human or policy approval bound to the exact plan that will execute.

MCP authorization can govern access to a server. Instrument-level authorization must additionally answer what this actor may do to this device, in its current state, for this workflow.

5. Telemetry and physical-state reconciliation

An agent cannot safely choose the next step from a tool response alone. It needs the instrument's observed state, terminal result, and any evidence that the expected physical effects occurred.

When telemetry disagrees with the planned state, the system should stop and reconcile. It should not let the language model invent an explanation and continue. This is the difference between an agent that can call hardware and an agent that can reliably close an experimental loop.

The Most Important Result in the MHS Demonstrations Is a Failure

The most informative part of Anthropic's announcement is not the fastest integration or the autonomous run. It is a liquid-handling failure.

In one reported experiment, the agent responded to errors caused by bubbles by retrying with changed parameters in the same well. The retry made the physical problem worse. A human expert had to explain that the software error was evidence of a fluid-behavior problem and that recovery required moving to a clean well and reducing the number of mixing cycles.

That example captures the central challenge of agentic lab automation. The instrument returned an error, but the correct recovery depended on physical and domain context outside the error code. The model's first response was plausible in software terms and wrong in laboratory terms.

The remedy was not unrestricted reasoning. The team converted the learned recovery into reusable operating knowledge. A production design should go one step further and encode safety-relevant parts as machine-checkable rules: when a retry is prohibited, when fresh labware is required, which parameters may change, and when an operator must intervene.

A separate August 2026 preprint on agentic operation of an atomic force microscope reports a similar architectural lesson. Its agent used MCP-connected instrument functions, while an ambiguity check guarded command execution and image post-processing was limited to a pre-approved tool set. The authors attribute zero wrong-command executions in their benchmark to the guarded execution layer, not to model capability alone. That result is specific to their tasks and setup, but the boundary is broadly useful.

What Instrument Vendors Can Build Now

Waiting for the final MHS specification does not need to mean waiting on agent readiness. The foundations below improve every integration path:

1. Publish a typed capability contract. Name operations, parameters, units, results, and declared errors. If the instrument already exposes OpenAPI, a vendor SDK, SiLA 2, or OPC UA, keep that contract authoritative.
2. Expose observable operation lifecycles. Long-running commands need stable identifiers, progress where meaningful, terminal states, results, and cancellation semantics.
3. Make limits executable. Put static and state-dependent constraints in code close to the instrument. Natural-language guidance can explain a rule; it should not be the only enforcement.
4. Separate intent from mechanics. Let an agent request a scientifically meaningful action while deterministic software expands it into low-level device commands. Our guide to reliable instrument agents explains why this tool-surface choice matters.
5. Define ambiguous-outcome recovery. Document what happens after a timeout, disconnect, restart, partial result, or late acknowledgement. Never make blind retries the default for sample-affecting actions.
6. Provide a simulation seam. The same high-level contract should be testable without physical hardware, with explicit limitations. Simulation supports integration tests, fault injection, and pre-execution verification.
7. Preserve protocol fidelity. Translation must disclose what it cannot carry. Our open-source OpenAPI to SiLA 2 generator explicitly detects constructs such as callbacks, streaming responses, binary bodies, and error schemas that need special handling rather than pretending every conversion is lossless.
8. Collect evidence for every consequential transition. Correlate the requested plan, approval, operation identifier, telemetry, terminal result, and reconciled state.

This work is not MHS-specific. It makes an instrument easier to integrate with MHS when the specification opens, and it improves today's APIs and automation systems at the same time.

Frequently Asked Questions

What is the Model Hardware Standard?

The Model Hardware Standard is an Anthropic-led research preview for connecting AI agents to programmable physical equipment through standardized drivers. Public materials describe device discovery, common state and operation descriptions, contextual hardware knowledge, enforced limits, and access through MCP, command-line tools, or code. The specification is not yet publicly available.

Is MHS the same as MCP?

No. MCP is a protocol through which AI applications discover and invoke tools. MHS is described as a hardware abstraction and driver model that can use MCP as one access mechanism. An MHS-connected instrument may appear as MCP tools, but MCP alone does not define the instrument's physical state or safety behavior.

Does MHS replace SiLA 2 or OPC UA LADS?

The public evidence does not support that conclusion. SiLA 2 and OPC UA LADS define laboratory-specific device capabilities, state, programs, results, and interoperability at layers below the agent. MHS may consume, wrap, or complement those contracts, but the exact relationship cannot be normative until its specification is public.

Can MHS make autonomous laboratory operation safe?

MHS can provide a common place for device knowledge and enforced limits, which is valuable. Safe operation still depends on the completeness of each driver, deterministic interlocks, current physical state, authorization, verified workflows, recovery behavior, and human oversight appropriate to the consequence. The research preview is explicitly being used to develop further safety evaluations.

Should an instrument manufacturer implement MHS now?

Organizations accepted into the preview can evaluate the actual specification and test it against bounded use cases. Other instrument teams can prepare without guessing: strengthen typed APIs, observable commands, limits, simulation, fault handling, and execution evidence. Those investments remain useful even if the MHS interface changes before open release.

From interface to trustworthy execution

MHS is a strong signal that AI-to-hardware integration is becoming a product requirement. The lasting advantage will not come from exposing the most tools fastest. It will come from making one valuable instrument workflow discoverable, verifiable, observable, and recoverable from end to end.

QPillars builds software at that boundary, from instrument contracts and protocol adapters to executable verification and state reconciliation. If you are evaluating how one instrument should participate in an agentic workflow, bring us the instrument and the workflow and we will map what the current interface already supports, what is missing, and which part should remain deterministic.