On August 27, Anthropic quietly opened a research preview of something that has been missing from the agent stack: a standard way for models to control physical hardware. The Model Hardware Standard (MHS) is a specification for AI agents to safely operate scientific instruments and manufacturing equipment — microscopes, robot arms, spectrometers, pipette robots, incubators, and custom devices.

If you've been building on the Model Context Protocol, the architecture will feel familiar. MHS is explicitly designed to work with MCP, not replace it. The MCP layer handles model–tool communication; MHS handles tool–device communication. Together they form a complete path from natural language intent to physical actuation.

What MHS Actually Is

At its core, MHS defines three things:

  • A device description format — machine-readable manifests that encode a device's physical constraints (weight, range, speed), adjustable parameters, measurement options, and enforced safety limits.
  • A communication protocol — a network transport layer so devices can talk to each other and to an agent without bespoke translator programs between every pair.
  • A safety tagging system — standardized metadata that lets a model with no prior training on a specific device understand its real-world boundaries before issuing a command.

Anthropic's announcement frames this as reducing weeks of experimental setup to "hours or minutes." The concrete example: a model like Claude adjusting a laser, checking results via a camera, then repeating to auto-calibrate the whole system — or focusing a microscope, analyzing the image, deciding where to look next, and moving the stage automatically.

Why It Lives Beside MCP

MCP solved the model–tool interface. But every lab instrument, robot arm, or CNC machine still speaks its own dialect — proprietary APIs, custom drivers, vendor SDKs. MHS doesn't replace those drivers; it wraps them in a common envelope so an agent can discover, address, and sequence them without custom integration code per device.

The Register's coverage notes that Anthropic demonstrated Claude reasoning through a robotic arm pickup task it had never been trained on, then writing API scripts to sequence steps across instruments. That's the MCP+MHS loop: the model reasons at the task level, MCP carries the tool calls, MHS translates to device commands, and the results feed back into the next reasoning step.

Critically, MHS devices can also be controlled directly via CLI or API — no model required. The standard is agnostic to what sits at the top of the stack.

What This Means for Developers

If you're building MCP servers

MHS doesn't change your server code today. But it signals where the protocol is heading: tool descriptions will need to carry physical constraint metadata (range, force limits, safety envelopes) alongside the current schema. The MCP tools/list response may grow an mhs extension field.

If you're building agent orchestration

Your planner now needs to reason about physical state — not just "call tool X" but "tool X moves a 2kg arm at 0.5m/s with a 10N force limit, and the workspace contains a $50k microscope." MHS's tagging system is designed to feed exactly this context into the model's working memory.

If you're building evals

Safety evals for virtual tools check for data exfiltration and prompt injection. Safety evals for MHS must check for collision, force exceedance, thermal runaway, and chemical hazard. Anthropic is explicitly inviting stakeholders to build these evaluations during the preview.

If you're in scientific computing or manufacturing

The preview is application-only, targeting research labs and advanced manufacturers. If you have instrument fleets that currently require weeks of custom integration, this is the signal to start documenting your device interfaces against the MHS schema.

The Bigger Picture

Anthropic's expanded AI for Science program — 10,000 free/discounted Claude seats for researchers, plus up to $50k credits per project — lands alongside MHS. The combination is deliberate: give scientists the model access, give the model a standard way to drive their equipment, and the bottleneck shifts from "how do I connect this" to "what experiment do I run next."

For the broader agent ecosystem, MHS is a proof point that MCP's architecture generalizes beyond software tools. The same "discover, describe, invoke, verify" loop that works for a filesystem or a browser works for a centrifuge. The protocol didn't change; the target domain did.

Expect to see MCP servers that expose MHS devices as tools within the next quarter. The first ones will wrap lab equipment; manufacturing and robotics will follow. If you're maintaining an MCP server registry or building an agent marketplace, plan for a new capability class: physical-actuation.

What to Watch

  • Open-source timeline. MHS is a "research preview" with access by application. Anthropic says they'll open-source it after safety evaluations mature. No date committed.
  • MCP spec integration. Watch the MCP GitHub repo for an MHS extension proposal — likely a new capability annotation on tool definitions.
  • Safety eval frameworks. The first third-party MHS safety benchmarks will define what "safe agent control of hardware" actually means in practice.
  • Hardware vendor adoption. If major instrument makers (Thermo Fisher, Tecan, Opentrons, Keyence) ship MHS-native firmware, the standard becomes a procurement requirement.

The gap between "model writes code" and "model moves atoms" just got a standard bridge. For developers who have been treating MCP as a way to call APIs, MHS is the signal to start thinking about what your tools touch in the physical world.

If this was useful, you can support my open-source work on Ko-fi or check out my services.