The Model Hardware Standard and What It Changes for Your Robot Arm

On 27 August 2026 Anthropic published the Model Hardware Standard, MHS for short. It is not a model and not a product. It is a specification for the layer that everyone who has ever pointed an agent at a physical device has written themselves, badly, at least once: the part that turns "close the gripper" into whatever bytes the servo bus expects, and that tells the agent what the device is before it touches it.

This article is the ordering piece. What the specification actually covers, what the research preview does and explicitly does not do, how it relates to MCP, and which questions are still unanswered. Everything below is either quoted from the announcement or from a named source with its address. Where the public record stops, this article says so rather than filling the gap.

What MHS actually is

Anthropic describes MHS as "a shared specification for AI agents to safely operate physical devices". Concretely that means a driver: a piece of software that sits in front of an instrument and exposes it through a deliberately small command vocabulary. The announcement gives the whole vocabulary in one line - "commands like 'read' (for example, 'get temperature') or 'write' (for example, 'set temperature')". Read and write. Everything a device can do has to be expressed in those terms.

The second half is description rather than control. The driver carries "tags that let the user write this information directly in natural language", and the announcement notes users can either write them themselves "or by chatting to an agent that interviews them about their hardware setup". On top of that sits discovery: MHS "makes each device discoverable in a standard format, so that devices and agents can find each other and communicate across networks without needing a bespoke 'translator' program in between". That last clause is the whole pitch in one sentence, and it is worth reading twice, because the bespoke translator program is exactly what most of us have sitting in a repository right now.

Read and write is a small vocabulary. Here is what one arm needs it to carry

A six-joint arm is close to the simplest manipulator there is, and its control surface really does fit into read and write. On our own hardware it is two calls: one read that returns the six joint angles and the gripper state, and one write that takes a motor name and an absolute angle in degrees. That is the same shape as get temperature and set temperature, which makes it a fair test of the vocabulary rather than a strawman - and the test is not whether the verbs are enough. They are. The test is what has to be true around them.

What the verbs do not carry is everything a caller has to know before it picks a number. Which names exist. In which unit. Inside which range, per joint. How far a single command may move something. How often one may be sent. And the one that gets skipped: what comes back when the driver says no. In MHS all of that belongs to the description half - the tags written in natural language - and the published record does not say what a description has to declare. The table below is the answer for one arm, taken from the driver that enforces it. It is an example of the problem, not a reading of the specification, because there is no specification to read.

One row in that table is worth more than the rest: the refusal. A driver that clamps quietly and answers with success teaches its caller a pose the arm never took, and the next command is then computed from a position that does not exist. Ours answers every write with applied and applied_position - whether the command reached the servo, and the angle that effectively did - and the browser client resyncs its own counter to applied_position for exactly that reason. The announcement describes safety limits enforced in the driver and says nothing about what the driver returns when one fires. That is not a hole in the idea. It is a hole in what has been published, and it is the first thing to look for when a specification does appear.

The table also hides a second problem, and it is the more honest one. Hand-driven commands and a running policy do not clamp against the same envelope on our stack: direct commands are clamped against limits compiled into the backend, a policy is clipped against a limits file shipped beside it. The gripper is where the two differ - 260 degrees of nominal span on one path, 68 on the other, because the policy path is clipped to the gripper's calibrated closed-to-open window rather than to its mechanical ends. Two paths, two files, one arm. Reconciling that is precisely the work a device description is supposed to absorb, which is why the next part is not a footnote.

A description that leaves out the unit switches the safety off quietly

Our device description is an actual file - config/joint_limits.json, shipped inside the client bundle next to the driver that reads it. Six joints, each with a servo id, a minimum, a maximum and a velocity ceiling; a control rate of 30 Hz; a watchdog that holds the arm in place if no new prediction arrives within 1500 milliseconds instead of letting it continue on the last one; and one offset that shifts a policy trained against an older gripper calibration into the frame the arm uses today. Twenty-seven numbers and one boolean. That is what a description of one very simple device looks like once it is written out rather than assumed.

The velocity field in that file is named max_velocity_rad_s and contains degrees per second. The name is historical, the loader still reads it, and the file says so in a comment on its first line. That sounds like housekeeping until you count what the ambiguity cost. During a conversion between radians and degrees, the clipping function received radian values and checked them against degree limits. The range clamp never fired, because every radian value fits comfortably inside a range written in degrees. The velocity clamp allowed 172 degrees of movement in a single tick. Nothing crashed, nothing logged an error, and the description file was still there and still being read - only the unit had drifted, and the unit was the part nobody had written into the contract.

The loader now refuses to be quiet about it. If the largest limit in the file is 10 or smaller in magnitude it prints a warning that the file looks like radians, on the reasoning that a six-joint arm whose entire envelope fits inside ten units is not an arm. Three lines, and they exist because the alternative was a safety path that looked healthy and did nothing. A format in which a human, or an agent interviewing a human, writes the tags in natural language will need an answer to that failure, and the announcement does not name one. It is the most specific question we would ask if we were reviewing the specification tomorrow.

The problem: one bridge per device, written by hand

The case Anthropic makes is an integration-cost case, not a capability case. "It typically takes a lab or manufacturing facility weeks, if not months, to set up and integrate their hardware", the announcement says, and MHS is supposed to reduce "this integration work to hours or minutes". Anyone who has wired a camera, a serial bus and a training loop into one process knows the shape of that cost: it is never one hard problem, it is thirty small incompatible ones, and each new instrument multiplies rather than adds.

The clearest illustration in the announcement comes from the HHMI Janelia Research Campus, where a two-photon microscopy rig is split across languages by vendor - "the detectors run in MATLAB, the cameras in Python, the electrophysiology in C#". Virginie Ruetten of the Ahrens lab describes what that used to cost: "Before MHS, integrating new pieces of hardware into the system was a multi-day project", and afterwards, "when I added a new camera... it took me only a few minutes". Connecting six instruments through MHS took under a week.

How MHS relates to MCP

This is where most of the second-hand coverage gets loose, so here is the exact sentence: MHS "is also model-agnostic, and any agent harness can access it using standard protocols, such as the Model Context Protocol". MHS is not MCP. The announcement presents MCP as one of three access paths rather than as the foundation, the other two being "the command line interface, and code files (APIs)". That is the whole of what the published record says about the relationship. Anything more specific - whether there is an MHS schema, how a driver declares itself, what the wire format looks like - is not documented anywhere public, and this article is not going to guess.

If the split between a question-answering surface and a device-moving surface sounds familiar, it should. We ended up in the same place on our own platform for unrelated reasons: the hosted MCP server answers questions about documentation, policies, robots and training jobs, and it can start and stop a training run - but it cannot move an arm. Moving the arm goes through the command line client, which is a different server with different tools. Two surfaces, two blast radii. MHS puts that same separation into a specification rather than leaving each of us to invent it.

That separation is checkable rather than promised, which is the only reason it is worth putting in an article about someone else's standard. The hosted server exposes 35 tools. 33 of them are annotated read-only, and the two that are not are start_training, which spends money on a rented GPU, and stop_training, which ends a run. No tool in that list accepts a joint or an angle. The local server, started with ay-robots mcp on the machine the arm is plugged into, has nine tools, of which exactly two move hardware and both refuse to run unless the caller sets a confirm flag. It also ships without things on purpose: there is no tool to overwrite a calibration, to set motor ids, or to unpair the machine. An agent should be able to use the arm, not to reconfigure it. The tool-by-tool walk-through of that server, including what the confirm flag is and is not worth, is a separate article.

What the research preview is

The first phase started on the day of the announcement with "a first group of scientific research labs and advanced manufacturers". Access is by application through modelhardwarestandard.com, which states the purpose in one sentence: "We're inviting stakeholders across science and industry to test the standard, build safety evaluations, and develop best practices for AI agents operating physical equipment before we open-source it." That page is a landing and application page. It carries no specification, no repository and no technical documentation.

The named research partners are Genentech, the University of Washington Baker and Pinglay labs, Carnegie Mellon University, HHMI Janelia, QuEra Computing and Tetsuwan Scientific. The hardware side is where a reader with an arm on the desk should look, and the announcement splits it into two groups. In the group it introduces as "Hardware vendors and the software companies that support them", it names AWS, Automata, Danaher, Doosan Robotics, MBF Bioscience, QIAGEN, Tecan and Universal Robots. Hugging Face and Raspberry Pi are not in that group: they appear further down, in the "Joining the research preview" section, as "early adopters" - Hugging Face "adding MHS support in LeRobot, their robotics library", and Raspberry Pi "enabling MHS integration across a number of their products following successful tests using their Camera MHS Driver". No date and no arm model are given for either.

One clarification, because it is easy to blur. The single LeRobot arm that appears in the announcement belongs to the University of Washington section, where PhD student Zihao Song writes that "we used an open-source robotic arm built on LeRobot, instrumented with MHS, to safely coordinate sample loading across multiple instruments". The page names no arm model there. That run, Hugging Face's LeRobot support, and our own run further down are three separate things and should not be read as one.

The runs that came with numbers

Genentech: a protein assay across three instruments

Genentech used MHS as a proof of concept for automating the BCA protein assay, coordinating a liquid handler, a robot arm and a plate reader as one procedure. The number that matters for anyone who has calibrated an actuator is the flow-rate optimisation: water at roughly 140 µL/s with an RMSE of 0.016, and viscous BSA at 10 µL/s with an RMSE of 0.181 - the same task, an order of magnitude apart in setpoint and an order of magnitude apart in residual, which is what fluid viscosity does to a pipetting model. The announcement also records that the agent hit "tip pickup failures and fluid detection errors, but managed to recover on its own". Recovering from a failed pick without a human is the interesting claim there, not the assay.

HHMI Janelia: heterogeneous instruments under one description

The Janelia case is the integration case rather than the control case, and it is covered above: a zebrafish sleep-research rig whose detectors, cameras and electrophysiology live in three different languages, six instruments connected in under a week, a new camera in minutes instead of days. What it demonstrates is a description layer that survives vendor heterogeneity. What it does not demonstrate is anything about closed-loop control of a manipulator.

QuEra: the one run with a blind test

QuEra applied MHS to laser frequency stabilisation and is worth singling out because it is one of only two partner results in the announcement that report a validation protocol rather than a demo - the other is the Carnegie Mellon fault-injection test further down. Recovery of a lost lock went from 150 seconds at 58 percent success to about six seconds at 96 percent in the overnight development run, and in the validation afterwards - the finished script re-tested "against the same randomized set of induced disturbances with no agent involved" - "across 700 trials, it recovered the correct lock 695 times, a 99.3% success rate". The 99.3 percent is therefore what the deterministic script the agent wrote scores on its own, not what an agent scores while driving; Anthropic calls the end product "a deterministic, fully inspectable script capable of running in production without an AI agent controlling it". QuEra published its own account of the run separately.

What Anthropic says does not work yet

This is the part most of the coverage dropped, and it is the part a practitioner should read first. The announcement is unusually direct about its own limits, and none of the following is external criticism - it is all in the primary source.

Two of those deserve a second look. The foaming example is the honest one: a model that has only ever read about liquids does not know that a bubble is a cause. If you work with a manipulator, substitute your own version - a servo that holds position but will not move because a firmware overload limit silently capped its torque looks, in a log, exactly like a planning error. Nothing in a read/write driver tells an agent which of the two it is looking at. And the overnight pause is the mirror image: a system that stops whenever it is unsure is safe and also, at some point, not automation.

The manipulator version of that is worth finishing, because unlike the foam it has an answer, and the answer says something about what a device standard would have to cover. A joint whose torque limit was silently capped is detectable: the commanded angle and the measured angle drift apart while the joint sits still and holds. Our recorder watches for exactly that - more than 20 degrees of divergence sustained for about a second - and the warning it prints names the suspect instead of the symptom: a silent torque cap in register 48. Confirming it takes one read. The diagnostics route reads the servo registers directly and returns the present torque limit from register 48 on its 0-to-1000 scale, the status byte from register 65 whose bit 5 is the overload flag, and the present load, which is what tells you the joint is trying rather than idle. The remedy is to write the limit back - we set it to 700 before a takeover, because enabling torque does not restore a capped limit on its own.

None of that is exotic, and none of it lives in the verbs. It is a list of registers a device promises to expose, with an agreed meaning per register, so that a caller can tell a physical failure from a planning failure without knowing the vendor. Read and write are enough to fetch them. The standardisation that would help is the promise that they are there and what they mean - and whether MHS covers that is not something the published record answers either way.

Safety, as far as it is documented

MHS enforces safety limits at the device level rather than relying on the agent to be careful - the example given is refusing excessive laser power in the QuEra setup. That is the right place for it: a limit that lives in the driver holds regardless of which model, which prompt, or which harness is driving, which is the only kind of limit worth having when the thing on the other end has mass and momentum. It is the same argument as a torque ceiling in servo firmware, one layer up.

What that test establishes is narrow and worth stating precisely: six anticipated fault conditions, in one setup, injected by the people who built it, all blocked. It is a real result and it is the kind of thing more hardware projects should publish. It is not evidence about unanticipated faults, it does not come with a published methodology anyone could re-run, and nobody outside has replicated it. Six is a small number in a space where the interesting failures are the ones nobody thought to inject.

A limit enforced in the driver cannot reach below the driver

One of the six conditions in that test is an active emergency stop, and refusing to move while an emergency stop is asserted is a driver-level check. It assumes the emergency stop is the layer underneath. On our own bench that assumption failed twice, and neither failure is exotic enough to leave out.

The first: our stop routes sit behind a bearer token, and during an incident a local call to one of them came back 401 - the wrong answer to give someone who is trying to halt an arm. The emergency stop is now a standalone script that talks to the servo bus directly. It needs no token, no running backend and no calibration data. It writes torque-enable zero to servos 1 to 6 on every serial port it finds, reads the register back to verify, and exits with 0 only when every servo is confirmed limp, 2 when one is not. It sits deliberately below the application, because that is where a stop belongs.

The second: a watchdog timer brings the backend back up within two minutes whenever it is not running, and the backend enables torque as it connects to an arm. On 10 August that pair undid three emergency stops in a row. Each stop worked. Each was reversed within two minutes by a timer doing its job correctly. The order is fixed now - stop the timer, then the service, then run the script - and the emergency modes drop an inhibit file for the watchdog to respect. Neither failure is a fault in a driver, and neither would be caught by injecting faults at the driver. That is not an argument against the Carnegie Mellon test, which is a real result and more than most projects publish. It is the reason six blocked conditions is a statement about one layer, and why the layer below it is the one to ask about.

What is still open

Disclosure. There is no public specification, no repository and no technical documentation. Anthropic states the intent - "We're sharing an early version of MHS with partners... ahead of making the standard open source" - and that "the drivers developed for each instrument have been standardized and will be made publicly available". No licence is named and no date is given. Speaking to The Register, Anthropic put the reason plainly: "There's more to learn before we open source MHS. LLMs still lack physical intuition, having learned about the physical world from text and images." Until something is published, "standard" is an intention rather than a description - you cannot implement against a document that does not exist.

Access. The preview is a first group, by application, with no published eligibility criteria and no stated size or duration. Nothing says whether a two-person shop with a 3D-printed arm is in scope or whether this is a phase for institutions with procurement departments.

Liability. Not a question Anthropic addresses at all, and worth flagging as someone else's analysis rather than anyone's position. Writing in TNW, the journalist points out that EU Regulation 2023/1230 replaces the Machinery Directive on 20 January 2027 and covers AI-based safety functions and machinery with self-evolving behaviour for the first time, and argues that "a specification that constrains a robot arm's speed and angles is performing a safety function" - so "in Europe, whoever writes that file may find they have written a regulated safety component". The regulation and its date are fact; the connection to MHS is the journalist's reading, not Anthropic's. It is still the right question to have in mind before you write a driver that other people's arms obey.

Whether the premise holds. The Register frames the launch against the fact that the vendor cannot reliably anticipate how its own models behave, and asks why that vendor is proposing the plumbing for physical equipment. Anthropic's answer is essentially the device-level limits above: constrain at the driver, not at the model. Whether that is sufficient is not something either party can settle by assertion, and the preview exists in part to find out. On the motivation from the other direction, Anthropic's Jonah Cool - described there as a head of partnerships and deployment at the company's life sciences arm - is quoted in Bloomberg-sourced reporting, carried on 28 August 2026 by The Star: "In many cases, the science doesn't happen because you can't use the equipment or it's too technically challenging." Fortune quotes him the day before on a second motive: "We want to avoid vendor lock-in for scientists."

What this means if you have an arm on the desk

Honestly: today, nothing, unless you are in the preview. There is no specification to implement, no package to install, no driver you can write. Hugging Face is listed as adding MHS support in LeRobot, which is the line that will eventually matter for an SO-100 or SO-101 - but no date and no arm model were given, and until that support lands there is nothing to point your hardware at.

What does not depend on MHS, and is worth having in place whether or not it ever ships, is the same short list that makes any agent integration survivable:

• A command surface with a hard ceiling in it, enforced below the caller. Per-call joint deltas clamped in the server, not in the prompt - the principle MHS calls device-level safety limits.
• A calibration you can repeat and check. Whatever your arm's zero is, it has to be recoverable after a power cycle without a person remembering a trick.
• Device state you can read back, not infer. If a joint holds position because a torque limit was capped, that has to be legible to whatever is driving.
• An audit trail per command, with who or what issued it. This is the part that stops mattering only until the first time something moves when it should not have.
• A separation between the surface that answers questions and the surface that moves metal, with different credentials on each.
• The unit written down where the limits are. A range without a unit is not a limit; it is a number that happens to be nearby.

If that list is where you are starting, our API reference documents the command surface we ended up with, the teleoperation docs cover the manual-control side, the security page covers credentials and scope, and calibration is written up separately because it is the step people skip and then pay for. If you want the whole chain once from arm to running policy, run your first policy is the short version, the desktop client is where recording and inference actually happen, and the DAgger loop is what you reach for when the policy is close but not right and you want to correct it on the hardware rather than retrain from scratch.

Disclosure, and one data point of our own

We took part in the MHS research preview. Our run was Claude Code driving a physical SO-ARM101 with nothing trained for it - no policy, no teleoperation, no demonstrations. The agent measured the workspace itself and wrote the motion. The calibration is the part we would point a fellow practitioner at: no checkerboard and no camera intrinsics, because the arm is its own ruler. Torque drops out, a human places the closed gripper on 16 points that the software draws into the camera view, and the robot reads back where they are. That gave 4.1 mm positional accuracy and 3.0 mm placement accuracy. Best run so far is 12 bricks placed with all four colour groups formed; a fully hands-off run from start to finish is still ahead of us. The run itself, including how those calibration numbers were arrived at, is written up in moving an SO-ARM101 without a policy, teleoperation, or demonstrations.

Those are our numbers from our setup. They are not part of Anthropic's published results, they are not the University of Washington LeRobot arm, and they are not Hugging Face's LeRobot support. We are describing participation in a research preview and nothing beyond that.

The useful thing about this announcement is not the promise; it is that the limits section is specific enough to argue with. Read that part, keep the numbers attached to the setups they came from, and check back when there is a specification to read.