Anthropic Announces Model Hardware Standard, MCP for Hardware?

What happened

Now I have rich, verified facts from the actual Anthropic announcement page. Let me write the article.

Anthropic opened a research preview of the Model Hardware Standard, or MHS, on August 27, 2026 — a shared specification that lets AI agents safely operate physical lab and manufacturing equipment. The standard began as a collaboration between Anthropic and the Howard Hughes Medical Institute Janelia Research Campus (HHMI Janelia Research Campus) and is now being extended to a broader group of partners in science, robotics, electronics, and advanced manufacturing before being released as open source.

This piece breaks down exactly what MHS is, how its driver and protocol layer work, which organizations are already building on it, and what builders and researchers should do right now if they want access. It is aimed at developers integrating AI agents with physical hardware, lab automation engineers, and anyone tracking how foundation-model companies are extending their protocol work beyond software.

How it works

Anthropic announced a research preview of the Model Hardware Standard, a specification for AI agents to discover, connect to, and safely control physical devices such as microscopes, liquid handlers, centrifuges, robotic arms, plate readers, pipette robots, spectrometers, and incubators. The project started as a direct partnership between Anthropic and HHMI Janelia Research Campus, with the goal of using AI to accelerate scientific research. Early partners from biotech, robotics, quantum computing, and manufacturing have already tested the standard ahead of this preview.

The announcement, published at anthropic.com/news/model-hardware-standard-research-preview, positions MHS as infrastructure for autonomous round-the-clock experiments. Anthropic notes that the standard works with any device that has a programmable interface, is model-agnostic, and is intended to become open source once safety evaluations and best practices have been established through the preview program.

Before MHS, integrating multiple lab or factory devices typically required specialists to build bespoke software translators for each piece of equipment, a process that took weeks or months. MHS replaces that with a standardized driver — software that sits between a computer's operating system and a hardware device and exposes a simple set of primitives: commands such as "read" (for example, "get temperature") and "write" (for example, "set temperature"). Each device implementing the MHS driver becomes discoverable in a standard format, so agents and devices can find each other across networks without a custom intermediary.

Why it matters

The driver also carries natural-language tags where users describe hardware characteristics that cannot be inferred from code alone, such as the physical weight of a robotic arm or the fluid properties a liquid handler must respect. The driver uses those tags to auto-generate a reference file the agent reads before operating the device. An agent can then control hardware through three mechanisms: the Model Context Protocol (MCP), the command line interface, or code files acting as APIs. This combination lets a single line of code orchestrate multiple instruments in parallel.

Lab automation engineers at scientific research institutions are the clearest immediate audience. If your facility currently maintains custom integration code for each instrument, MHS replaces that per-device work with a single driver standard, potentially compressing setup from weeks to hours. Genentech researchers demonstrated this on a workstation combining a liquid handler, a robotic arm, and a microplate reader to automate the bicinchoninic acid (BCA) protein assay; Claude, operating through MHS, independently optimized flow rates, converging on approximately 140 µL/s for water (RMSE 0.016) and 10 µL/s for viscous bovine serum albumin samples (RMSE 0.181).

Who is affected

Developers building agent harnesses on any model should also pay attention. Because MHS is explicitly model-agnostic and supports MCP as a standard access protocol, any agent framework that already speaks MCP can connect to MHS-compliant devices without Anthropic-specific changes. Zihao Song, a PhD student in the University of Washington Baker and Pinglay labs, used MHS to build a remote instrument monitoring dashboard, an AI-supervised qPCR workflow that watches amplification curves and halts the run at the correct moment, and a collision-free plate handoff system between a robotic arm and a liquid handler — all during the early preview phase.

MHS is currently in a limited research preview. Access is by application only; the application form is hosted at modelhardwarestandard.com via a Google Forms link. Anthropic is prioritizing stakeholders across science and industry who can contribute to safety evaluations and best practices for AI agents operating physical equipment. There is no announced timeline for general availability or for the open-source release, so builders should apply early and expect the preview to move at the pace of safety iteration rather than a fixed product calendar.

Builders who gain access should plan to implement the MHS driver for each device in their stack and write the natural-language hardware-description tags that the driver needs to generate a device reference file. The reference file is what the agent reads to understand a device it has never encountered. Three control paths are available — MCP, CLI, and code-file APIs — and teams running long-duration experiments will likely reach for code files to chain driver commands so devices can execute autonomously between agent reasoning steps.

What to watch next

The most consequential near-term question is what the safety-evaluation process produces before open-source release. Anthropic is explicitly inviting preview partners to help build those evaluations, which means the scope of what an MHS-connected agent is permitted to do autonomously will be shaped by real experimental data from Genentech, the University of Washington Baker and Pinglay labs, and other unnamed partners in quantum computing and advanced manufacturing. Builders should watch for published safety guidelines or constraint primitives that will likely accompany or precede the open-source drop.

The second thing to track is how MCP integration matures as MHS scales. MCP is already one of three supported control mechanisms, and Anthropic's pattern with the Model Context Protocol — announce a spec, open-source it, then encourage third-party adoption — suggests MHS will follow a similar path. Teams building on MCP today for software tooling should verify whether their existing MCP server infrastructure can be extended to hardware device endpoints, and whether device-side latency and safety constraints require changes to how their agent harnesses handle long-running or irreversible tool calls.