MHS Specification: A Public Preview Summary

This MHS specification page is a structured summary of publicly described research-preview information. It is not the official MHS specification, does not define conformance, and may become incomplete as the preview evolves. It is designed to help readers understand the concepts that are public without filling in unpublished schemas, version rules, or implementation requirements.

Independent resource: MHSBase is an unofficial, independent community resource. It is not affiliated with or endorsed by the Model Hardware Standard project or its contributors, and it is not the official MHS website.

Updated: August 28, 2026

MHS specification: what is public today

The public description presents MHS as a shared approach for AI agents to safely operate physical devices with programmable interfaces. It is model-agnostic in its stated intent and is relevant to scientific research, robotics, electronics, manufacturing, and other settings where software must coordinate equipment.

The public material should be read as a preview description, not as a complete standards document. It explains the design goals and several building blocks, but it does not give readers everything needed to claim compatibility. A real implementation still has to connect a device, translate its interface, test its behavior, define its limits, and validate the complete workflow.

The phrase MHS documentation can therefore refer to two different things. It can mean the official project material that describes the preview, or it can mean independent explainers such as this page. MHSBase uses the second meaning here. We organize public concepts for readers, but we do not publish a substitute for an official release.

For a plain-language introduction, start with What Is MHS?. For the current access context, read the MHS research preview guide.

Scope and design goals

MHS is focused on the boundary between software and physical equipment. A microscope, liquid handler, robotic arm, camera, sensor, or laser system can keep its own mechanics and native vendor software. The common layer is intended to make the device easier for an agent or another application to describe, discover, observe, and operate.

The goal is not to make every instrument identical. The goal is to reduce the amount of one-off integration needed when a workflow combines devices that were built by different vendors, use different programming interfaces, or run on different computers. A consistent description can make the differences visible and manageable instead of burying them in undocumented glue code.

This focus also explains why MHS hardware is more than a list of supported product names. A useful integration needs to describe what the device can measure, what it can change, which operations are available, what state it reports, and what limits apply. Hardware support is a relationship between a real device, its driver, its environment, and the workflow that uses it.

The public building blocks

MHS driver

The public preview describes a standardized driver as software that translates between a computer and a hardware device. The driver is the place where a device-specific API, SDK, command line, file workflow, or other programmable interface can be adapted to a more consistent control surface.

An MHS driver should make the device legible to the rest of the system. In practical terms, a reader should be able to ask what the device is, what it can measure, which controls it exposes, what operations it supports, and how it reports progress or failure. The preview does not prescribe one complete code layout for every driver, so this description is a design concept rather than a ready-made SDK contract.

MHS read write primitives

The public examples use simple MHS read write primitives, such as reading a temperature or writing a new temperature setting. The example is intentionally easy to understand: an agent needs a reliable way to observe state and a defined way to request a permitted change.

The same pattern can apply to a plate position, a laser frequency, a camera stream, a sensor reading, a liquid volume, or the state of a long-running protocol. The operation names will vary by device, but the workflow needs to know the input, output, unit, completion signal, and failure behavior. Without that context, a tool call may be syntactically valid while still being operationally unclear.

MHS device discovery

MHS device discovery is the idea that connected equipment can be found and described through a consistent format. A workflow should not rely entirely on a private hostname list, a directory of undocumented scripts, or one operator remembering which computer controls which instrument.

Discovery is useful only if the description carries enough meaning. A name is not a capability statement. An agent needs to know whether a device is ready, which measurements are current, what operations are possible, and how it relates to the other devices in the workflow. Identity, capabilities, state, units, and constraints belong in the review of an integration.

Context and reference information

The public description also discusses natural-language tags and reference information. Some facts that matter to safe operation are not obvious from an API. A robot arm's physical characteristics, a sensor's range, a sample's sensitivity, or a laser's operating boundary may live in a manual or in an experienced operator's knowledge.

Tags and reference material can make this context easier to expose to an agent. The project description says a driver can produce a reference file covering general characteristics, measurements, adjustable values, and safety limits. That information still needs expert review. A readable reference is not proof that a device has been completely or correctly described.

MHS safety limits

MHS safety limits are part of the reason device context matters. A physical action can waste a sample, damage an instrument, or create a hazardous state. Making limits visible and enforceable can help an agent avoid actions outside the intended operating envelope.

Safety should remain layered. A driver-level limit does not replace an emergency stop, a physical interlock, a human approval point, a facility procedure, or a test of failure behavior. Teams need to decide which actions are reversible, which are high risk, when a person must approve them, and how an operator can take over.

Access mechanisms

The public preview names several ways to control hardware through MHS, including MCP, a command-line interface, and code files or APIs. This distinction matters because MHS is not defined as one access protocol. An access mechanism is the route by which an agent or application reaches a capability; the driver and device description explain what that capability means.

Read MHS vs MCP for a role-by-role comparison. The important point is that MCP is one supported access mechanism in the public description, not the whole MHS specification and not a substitute for accurate device integration.

A practical conceptual model

The following questions are a useful engineering checklist, not an official schema:

1. Identity: What physical device or service is being controlled?
2. State: What can the system observe right now, with units, timestamps, and freshness?
3. Operations: What actions can be requested, with explicit inputs and outputs?
4. Constraints: Which limits, interlocks, permissions, and approvals apply?
5. Coordination: How does this device interact with other devices in the same workflow?
6. Failure: How is an error reported, and what is the safe next step?
7. Evidence: How will the team know that the operation did what it was supposed to do?

This checklist helps reveal gaps before an agent is given control. A measurement without a unit can be ambiguous. An action without a completion signal can cause a collision or an out-of-order step. A limit without a test can be only a comment in a file. The checklist is intentionally more demanding than a list of tool names because real equipment requires operational context.

From device description to orchestration

A possible workflow starts by connecting a programmable device and adapting its native interface through a driver. The team then records capabilities, state, operations, units, characteristics, and safety boundaries. An application or agent discovers the device, reads its current state, requests an allowed operation, and checks the result.

When several devices are involved, orchestration adds timing and dependency. A liquid handler may need to report that dispensing is complete before a robotic arm moves a plate. A camera may need to confirm a position before a transfer begins. A reader may return data that determines whether the next protocol step should continue or repeat.

An agent can make decisions at selected points, while a deterministic code file handles a repeatable sequence at device speed. This division can make behavior easier to inspect. It also creates more places to test: the driver, the access mechanism, the orchestration logic, the physical device, and the interpretation of results.

The MHS use cases page collects public examples of this pattern in laboratory automation, microscopy, qPCR, and quantum-device control.

What this MHS documentation does not define

The public preview description does not, by itself, provide a complete normative schema, versioning policy, conformance test suite, certification program, universal device-support list, or production service-level guarantee. MHSBase does not invent those details and does not turn a concept summary into an implementation contract.

The same caution applies to performance claims. A reported result may depend on a particular instrument, driver, model, sample, facility, induced failure, or test procedure. Readers should not infer that a result from one setup automatically transfers to another setup.

The preview also appears to be an early collaboration phase. The project materials describe work on safety evaluations, best practices, partner feedback, and a future open-source direction. A future direction is not the same as a finalized release that is stable for every use case.

How to use this page

Use this page to build vocabulary and a review checklist. Use What Is MHS? when explaining the idea to a new reader. Use MHS vs MCP when a design discussion mixes the device-control layer with an access protocol. Use the MHS research preview guide when you need the current application context.

If you are evaluating a real integration, document the device interface, the driver behavior, the state model, the allowed operations, the safety limits, the human approval points, and the evidence that will be collected. Keep the scope small enough to test end to end before expanding to a larger fleet or a more autonomous workflow.

Conclusion: what the MHS specification tells us today

The public MHS specification story is clear at the level of intent: standardize how programmable physical devices describe state and operations, make them discoverable, carry the context and limits an agent needs, and provide several ways to access and orchestrate them. It is not yet clear enough to support claims about a final schema, compatibility certification, or universal implementation behavior.

That distinction is the most important takeaway. MHS can be a useful organizing idea for MHS documentation, drivers, device discovery, read/write operations, and safety review, while the exact implementation remains subject to the preview's development. Treat this page as an independent map, follow the internal guides for context, and verify changes against the project's public materials.

Sources

• The Model Hardware Standard project's public research preview announcement and project materials.
• For current access information, see the MHS research preview guide.