MHS and MCP : Accessing from Software to Hardware

AI assistants used to live mostly inside chat boxes. You gave them a question, they gave you an answer, and everyone pretended that the answer was grounded in reality.

Then we connected them to files, GitHub repositories, databases, calendars, Slack, and APIs. Suddenly, the assistant was not just talking about the world. It could look things up, call tools, and act on information outside its conversational bubble.

That shift is what the Model Context Protocol, or MCP, is about. Now Anthropic is taking the same idea one layer closer to reality with the Model Hardware Standard, or MHS. MCP helps AI agents work with the digital world, while MHS helps AI agents work with the physical world.

One gives the model access to your documents. The other might eventually give it access to a microscope, a liquid handler, a robotic arm, or a laser calibration setup. This feels like a small naming update until you think about the difference between deleting a file and moving a robot arm: one gives you a bad afternoon, while the other gives you a bad incident report.

First, what problem was MCP solving?

Before MCP, connecting an AI assistant to a new data source usually meant building a custom integration. Want the model to read Google Drive? Build a connector. Want it to search GitHub? Build another connector. Want it to interact with Slack, Postgres, or an internal business tool? More connectors.

Every tool had its own authentication, data format, API conventions, and failure modes. The model might be intelligent, but it was surrounded by disconnected islands of information.

Anthropic introduced MCP as an open standard on November 25, 2024. Its goal was to create a common way for AI applications to connect to external systems instead of requiring a new one-off integration for every data source.

The architecture is fairly simple:

• An MCP server exposes data or capabilities.
• An MCP client connects an AI application to those servers.
• The model can then discover and use available tools, resources, and prompts.

You can think of MCP as a universal adapter between an AI application and the systems around it. It is not exactly a USB-C port for intelligence, but it is close enough for a Tuesday afternoon explanation.

The important idea is that the model should not need to understand every company’s internal API from scratch. It should be able to interact with a consistent interface. Instead of teaching the assistant 50 completely different dialects, we give it a common grammar.

That is useful because context is often the difference between a confident answer and a useful answer. An assistant that only sees your current prompt may give you something plausible, but an assistant that can inspect the relevant code, documentation, issue history, database records, and team discussions has a better chance of giving you something that actually fits.

That does not make it automatically correct. It just means we have stopped asking it to solve a puzzle while hiding half the pieces.

A small piece of MCP history

MCP was created at Anthropic by David Soria Parra and Justin Spahr-Summers. The initial release included an open specification, SDKs, local Claude Desktop support, and open-source server implementations for systems such as Google Drive, Slack, GitHub, Git, Postgres, and Puppeteer.

There is a funny pattern in infrastructure history: a technology becomes important not only when it is powerful, but when it becomes boring enough for other people to build on.

HTTP became boring. Linux became boring. Containers became boring. That is not an insult. It is the dream.

MCP is trying to become boring in the same way. If it works, developers should not need to care which connector was hand-built by which team on which sleep-deprived weekend. They should be able to connect an agent to a system and focus on the actual problem.

Of course, the moment you give an AI assistant access to real systems, security becomes part of the conversation. A tool that can read your documents is one thing. A tool that can send emails, delete records, deploy code, or move money is another.

MCP creates a standardized connection layer, but it does not magically make every connected tool safe. Permissions, authentication, approval flows, logging, and human oversight still matter. The adapter can be universal, but your security policy should not be.

Then Anthropic introduced MHS

On August 27, 2026, Anthropic announced a research preview of the Model Hardware Standard. MHS is designed to help AI agents safely operate physical devices with programmable interfaces, including scientific instruments, manufacturing equipment, microscopes, liquid handlers, and robotic arms.

This is the part where the phrase “AI agent” starts feeling less like a software product category and more like a job description.

MHS addresses a problem that researchers and engineers have dealt with for years: hardware is fragmented. A lab may have a camera from one vendor, a laser from another, a motorized focuser from a third, and a control system written by somebody who left the institution in 2014. All of these devices may work perfectly on their own. Together, they speak different languages.

MHS introduces a standardized driver layer. The driver translates between the device and the software controlling it. Anthropic describes simple primitives such as read, for retrieving something like temperature, and write, for changing something like a set point.

The idea is not to make every machine identical. The idea is to make every machine understandable.

A microscope does not need to pretend it is a robot arm. A centrifuge does not need to become a database. They just need to expose their state, capabilities, and constraints in a format that an agent can discover and reason about.

MHS also includes information that usually lives in manuals, setup notes, or someone’s memory: how heavy the robot arm is, what temperatures are safe, what the machine can measure, what must never happen, and what a particular error means physically.

Some of this information is technical. Some of it is tacit knowledge. Some of it is the sentence a lab technician says while pointing at a machine:

“Do not touch that button unless you want the entire afternoon to become a story.”

MHS tries to make that knowledge explicit and available to the agent.

MCP and MHS are different layers

The cleanest way I understand the relationship is this: MCP connects the agent to software, data, and digital tools, while MHS connects the agent to devices and physical processes.

MHS can use MCP, along with command-line interfaces and code files, to control and orchestrate multiple devices.

So an agent might read an experimental protocol from a document, inspect the current state of several instruments, adjust a device, observe the result through a camera or sensor, update the next step, and save the successful process as a deterministic script.

That last step is especially interesting. Anthropic describes Claude exploring a laser setup, observing how adjustments changed the laser beam, and eventually packaging what it learned into a script that could repeat the alignment without requiring the model to reason through every tiny step again.

This is a useful division of labor. The agent explores, the script repeats, and the human supervises. The hardware does not need a language model narrating every millisecond of a procedure. Once the correct sequence is known, normal code can execute it faster and more predictably.

AI agent: “I have discovered a procedure.”
Engineer: “Great. Now put it in a script before you get creative again.”

The most exciting part is the boring part

The headline is “AI operates laboratory equipment.” The deeper story is standardization.

The exciting thing is not necessarily that a model can call a function named set_temperature. We have had software interfaces for a long time. The exciting thing is that the model may be able to discover an unfamiliar device, understand its operating limits, coordinate it with other devices, and recover from certain failures through a shared interface.

That is a much bigger shift than simply adding a chatbot to a machine. It moves us from asking, “Can AI control this device?” to asking, “Can AI understand an entire environment made of many devices?”

That is the difference between giving someone a remote control and giving them responsibility for a factory floor.

My perspective is that MHS is not really “MCP 2.0.” It is MCP with consequences.

MCP deals with context in the digital world. If an agent reads the wrong document, the result may be inaccurate. MHS deals with context in the physical world. If an agent misunderstands a temperature limit, a sample could be ruined. If it misreads a sensor, a robot could move incorrectly. If it mistakes a physical failure for a software failure, it may try the wrong fix repeatedly.

The error is no longer just a bad paragraph. The error has mass, heat, motion, and sometimes a very expensive replacement part.

A quick history fact from the lab

MHS began as a collaboration between Anthropic and HHMI Janelia Research Campus.

At Janelia, researcher Arco Bast was working with a brain-imaging setup involving lasers, motorized focusers, and specialized cameras from different vendors. He created a shared-memory dictionary so the instruments could communicate with one another quickly. Anthropic’s Alek Kemeny then worked with him to integrate AI models into that interface.

I like this origin story because it is not “someone had a futuristic idea in a conference room.” It is a practical engineering problem: several machines needed to cooperate, their interfaces did not line up, and someone built a layer to make them communicate.

That is how a lot of important infrastructure begins. Not with a perfect master plan, but with one person being tired of manually translating between systems.

The safety problem is much harder now

MHS is still a research preview, not a finished universal solution. Anthropic explicitly notes that current models have limitations in spatial and physical reasoning and still require expert oversight. It also notes that MHS does not yet work with hardware that lacks a programmable interface.

That limitation is important. A model may understand the sentence “the sample is foaming,” but that does not mean it understands the physical consequences of foam inside a biological workflow.

Software often gives us clean abstractions. The physical world is less cooperative. A function either returns an error or it does not, but a real machine can be technically online while something inside it is misaligned, overheated, contaminated, empty, vibrating, or about to become a problem.

This is why safety cannot just mean “the agent has a list of forbidden commands.” A safe hardware system also needs state awareness, physical limits, sensor validation, emergency stops, permission boundaries, human escalation, reversible actions where possible, and clear logs of what happened and why.

The word “write” sounds harmless in an API. In the real world, “write” might mean “move a robot,” “increase pressure,” “open a valve,” or “change the conditions of a biological experiment.”

The interface can be simple. The consequences are not.

What happens when MCP meets MHS?

Imagine an agent with access to a research paper through an MCP server, an internal experiment plan, historical results in a database, a microscope through MHS, a robotic liquid handler through MHS, a sensor stream from another device, and a code environment for writing repeatable procedures.

The agent could connect knowledge to action. It could read what researchers want to test, inspect the instruments available, plan a sequence, run the experiment, monitor the result, and save the outcome for the next iteration.

That does not mean fully autonomous science is arriving tomorrow morning. It means the walls between software, data, and equipment are becoming thinner.

Today, many scientific workflows are limited by integration work. The instrument may be capable, but connecting it to the rest of the workflow takes weeks or months. If a standard reduces that work to hours or minutes, the impact may come less from making individual machines smarter and more from making entire environments easier to reconfigure.

The future may not be one magical robot scientist. It may be thousands of ordinary instruments that can finally coordinate with each other.

My take

MCP gave AI a way to leave the chat window. MHS gives that idea a path toward leaving the screen entirely.

But the winner will not be the system that gives agents the most power. It will be the system that makes their power understandable, constrained, inspectable, and boring enough to trust.

The best hardware agent should not feel like a reckless genius improvising near a laser. It should feel like a careful operator that knows what it can do, knows what it cannot do, and asks for help before turning a small uncertainty into a large repair bill.

MCP made context portable. MHS is trying to make capability portable. That is a much bigger responsibility.

So I have a few questions for you:

• Would you trust an AI agent to run a lab experiment if every action required approval?
• What should always require human confirmation?
• Is a standardized interface enough, or do we also need standardized safety policies?
• Which industry would benefit most from MHS: biotech, robotics, manufacturing, or quantum computing?
• Would you let an agent operate your 3D printer unattended?

Personally, I am excited by the boring infrastructure layer: drivers, manifests, state dictionaries, limits, logs, and repeatable scripts. The flashy demo is an agent moving a robot arm, but the real breakthrough may be that the robot arm, the camera, the sensor, and the database finally agree on what is happening.

That is when AI stops being just a model with tools and becomes part of a system. Systems, unlike chatbots, have to live with the physical world.

MCP gave AI a context window. MHS may give it a workshop. The hard part is making sure it reads the safety manual before touching anything.

Sources

• Anthropic: Previewing the Model Hardware Standard
• Anthropic: Introducing the Model Context Protocol
• Model Context Protocol documentation