UHP vs Model Hardware Standard (MHS)

The one-sentence difference

UHP is a live client-to-server contract for running complete agent harnesses; MHS is a device-integration layer for describing, discovering and controlling programmable physical equipment through standardized drivers.

The two therefore sit at different boundaries. A UHP client can ask a selected harness to do work; an MHS-enabled harness can then interact with physical devices as part of that work.

Status first

• UHP is 2026-08-11, a Draft standard with a public 52-check conformance suite (2026.8.11.post1).
• MHS was announced by Anthropic on 27 August 2026 as a research preview, initially developed with HHMI Janelia Research Campus.
• Anthropic describes the preview as an early version shared with a limited group of research laboratories and advanced manufacturers ahead of making the standard open source. The public MHS landing page likewise describes access as a limited research preview.
• No public versioned normative MHS specification, open-source reference repository or MHS conformance suite was identified in this 29 August 2026 verification pass. That makes MHS materially real, but still earlier in standardization maturity than UHP’s already-public specification and test suite.
• MHS is explicitly model-agnostic. Anthropic says any agent harness can access it using standard protocols such as MCP; the preview also exposes command-line and code/API control paths.

Architectural comparison

Dimension	UHP	Model Hardware Standard (MHS)
Primary boundary	Client/product ↔ UHP server ↔ complete agent harness	Agent harness/software ↔ MHS driver ↔ programmable physical device
Main purpose	Standardize task, session, streaming, cancellation, file and artifact interaction with a harness	Standardize how heterogeneous physical equipment is described, discovered and controlled
Core abstraction	Harnesses, responses, sessions, containers, files, artifacts and events	Standardized device driver plus device metadata/reference information and read/write-style primitives
Discovery	UHP discovery and harness/model catalogues	Standard-format device discovery plus generated device reference information
Control surface	HTTP/SSE UHP protocol	MCP, command-line interface and code/API paths into MHS drivers
Long-running work	UHP defines task/session lifecycle and continuation	MHS can chain driver commands into deterministic code files so devices can execute without model reasoning at every step
Safety boundary	UHP defines protocol/security requirements around harness execution	MHS device metadata can describe physical characteristics and safety limits that the driver enforces
Physical effects	Indirect; UHP itself does not define a hardware-driver standard	Directly in scope: lab, robotics, manufacturing and other programmable equipment
Maturity	Public Draft 2026-08-11 with public conformance suite	Limited research preview; public open-source standardization is stated as future work
UHP relationship	Normative protocol	No standardized UHP↔MHS binding established

How the public MHS preview works

Anthropic’s public description identifies four important pieces.

1. A standardized driver. MHS translates between software and device-specific programming interfaces using a small common primitive set such as reading state or writing/setting state.
2. Portable device discovery and reference data. Devices expose a standard discoverable representation. Natural-language tags can capture operational knowledge that is otherwise trapped in manuals or local expertise; MHS can use those tags to generate a reference file describing capabilities, adjustable parameters and enforced safety limits.
3. Multiple access mechanisms. The preview exposes devices through MCP, a CLI and code files/APIs. MCP is therefore one concrete way for an agent harness to reach the MHS device layer, not the definition of MHS itself.
4. A deterministic execution path for speed or duration. For long-running operations or tasks that need faster control than online model reasoning permits, the agent can compose driver commands into code files and let the devices execute those steps directly.

This is a materially different problem from standardizing a complete harness. MHS makes physical equipment more portable to harnesses; UHP makes complete harness runtimes more portable to clients.

Where UHP, MCP and MHS can compose

One plausible layered architecture is:

Client / product
      ↓ UHP
UHP server
      ↓
Selected agent harness
      ↓ MCP / CLI / code API
MHS driver layer
      ↓
Physical devices

That diagram is an architectural composition, not a standardized binding. Current evidence does not define a UHP field, endpoint, content type or conformance requirement for MHS, and it does not require a UHP implementation to expose MHS-capable hardware.

MCP has the more direct relationship in Anthropic’s public description because an MHS-enabled device surface can be presented to a harness through MCP. Even then, MHS remains a separate hardware-integration standard: using MCP as an access mechanism does not make MHS part of the MCP core specification.

Why MHS matters to harness interoperability

MHS extends the interoperability discussion beyond software-only tools. A harness that can understand one common driver/discovery model can potentially move between laboratory instruments, robotic arms and manufacturing equipment without rebuilding bespoke integrations for every vendor interface.

That creates a new downstream portability layer:

• UHP: portable client access to a complete harness.
• MCP: portable access to tools/resources/context surfaces that a harness can consume.
• MHS: portable description and control of programmable physical equipment that can be exposed to the harness, including through MCP.

The layers can be complementary, but their conformance and trust questions remain separate. A UHP-conformant server is not automatically MHS-compatible, and an MHS-enabled device or harness is not automatically a UHP implementation.

Early implementation signals

Anthropic’s preview announcement names real proof-of-concept and partner work across scientific research, robotics and manufacturing. Public examples include Genentech laboratory automation and University of Washington laboratory workflows. Anthropic also lists broader work or planned integrations involving organizations and platforms including AWS, Hugging Face/LeRobot, Raspberry Pi and multiple hardware manufacturers.

These are meaningful ecosystem signals because they show MHS being tested against heterogeneous real equipment rather than existing only as a concept paper. They should not be overstated: the public materials still label MHS a research preview, access is limited, and the open-source standard itself has not yet been published.

What MHS does not establish

• It does not change UHP 2026-08-11 or its conformance requirements.
• It does not establish a standardized UHP↔MHS binding.
• It does not establish HarnessRouter support for MHS; no such integration was verified in this pass.
• It does not establish native UHP adoption by Anthropic, HHMI Janelia or any MHS preview partner.
• It does not turn MCP into a physical-device standard merely because MCP is one MHS access mechanism.
• It does not yet provide a public MHS conformance result or certification surface that can be compared with UHP’s 52-check suite.
• It should not be treated as a finalized open standard until the promised open-source specification and its versioning/conformance model are actually published.

Related pages

Read UHP vs MCP for the tool/context boundary, Harness composition for internal runtime topology, UHP security for execution trust boundaries, and the ecosystem map for adjacent standards.

Primary sources

• Anthropic: Previewing the Model Hardware Standard (27 Aug 2026)
• Model Hardware Standard — official research-preview site
• UHP 2026-08-11 architecture
• MCP 2026-07-28 specification