A_Protocol_Shape,_Not_a_Product

This is a research preview limited to scientific-research and advanced-manufacturing partners, with no public SDK. I built EXP_039, a simulated hardware-control protocol, against the specification Anthropic describes: device discovery, a capability manifest, and read/write command primitives. It runs at /playground/mhs-hardware-controller, entirely in the browser, with no connection to Anthropic's real SDK anywhere in the loop.

Modelling a protocol shape you cannot call is a particular kind of exercise. There is no real driver downstream to catch a lazy decision for you, so the parts the announcement leaves vague become the parts you have to answer yourself. Three of those answers matter more, I think, than the announcement itself.

A_Capability_Manifest_Needs_Two_Ceilings,_Not_One

The announcement's phrasing is "what can be adjusted, and what safety limits will be enforced." Read quickly, that sounds like one number: a maximum. It is not. In mhsProtocol.ts, every DeviceParameter carries both a max and a separate safetyLimit. In the installation's device data (devices.ts), the two are not always equal: motor-01's speed parameter has a physical range of 0 to 60 rpm and a safety limit of 45. Sixty is what the actuator can do. Forty-five is what the driver will let an agent ask for before it refuses.

That distinction only earns its place if the two failure modes stay distinguishable. mhs-hardware-controller-engine.test.ts checks for exactly that: a write of 50 rpm, in range but over the safety limit, comes back rejected with a reason matching "safety limit"; a write of 200 rpm, out of range entirely, comes back rejected with a reason matching "outside range." They are separate tests, not one shared "invalid value" case. Collapse them into a single generic rejection and an agent loses the ability to tell "recompute the value" apart from "don't ask for that at all," which are different corrections a single error message cannot carry.

Read_and_Write_Are_Not_the_Same_Shape

ControlCommandSchema in mhsProtocol.ts is a discriminated union on kind, not one object with an optional value field. A read command carries a deviceId and a parameter. A write command carries those plus a required value. The alternative, one schema with value marked optional and checked at runtime, pushes a structural distinction into a validation function, where a future edit can quietly erode it. The discriminated union means a write command missing its value fails to parse at the schema boundary before any handler code runs, which is exactly what mhs-hardware-controller-protocol.test.ts asserts directly.

It is a small decision on the page. It is the one I would defend hardest, because "read" and "write" are not cosmetically different verbs sitting on the same object. They are different contracts, and the schema should say so rather than leaving it to a comment.

The_Model's_Output_Is_Never_Pre-Validated

This is the one the announcement's own phrasing risks underselling, because "capability negotiation" sounds like something that happens once, upfront, and is then trusted. MhsHardwareControllerExperiment.tsx sends the intent and the current capability manifests to the route in one request, gets an AgentCommandBatch back, and re-validates it client-side against AgentCommandBatchSchema before touching anything, on top of whatever the route already checked server-side. Every command inside that batch then runs through SimulatedInstallation.applyCommand(), which independently checks the device exists, the parameter exists, the access mode allows the operation, the value sits inside [min, max], and the value sits under safetyLimit.

The system prompt in mhsHardwareController.ts does ask the model to self-constrain: only reference real devices, respect access modes, stay under the safety limit. That instruction is a courtesy to the model, not a control. The header comment in mhsHardwareController.ts says it directly: the prompt asks the model to self-constrain first, but the installation re-validates and can still reject a command regardless of the instruction. Whatever the reasoning trace claims, the actuator only ever sees what survives the second check.

One adjacent thread worth naming and setting aside in the same breath: the retail and transaction side of this same agent-to-real-world shift, Tencent's WorkBuddy and Anthropic's own commerce templates among them, is a different protocol problem, moving money rather than motors, and it is getting its own piece later.

What_I'd_Carry_Into_a_Real_Installation

I run experiential installations for a living, not simulated ones, and building this changed what I would ask for on the next one that puts an agent anywhere near an actuator.

I would refuse a capability manifest that only publishes a range. If I am signing off on an installation where an agent can move something, I want the safety ceiling stated separately from the physical maximum, and I want the two failure modes distinguishable in whatever log I am reading afterwards, the same way I built the tests here to check two rejection reasons rather than one.

If a vendor told me their kinetic rig trusts the model's own reasoning trace as the safety check, I would ask where the independent revalidation happens, because in EXP_039 that revalidation is the thing standing between "the model said it would stay under 45" and an actuator that never receives a value above 45, whatever the model said.

I would also want read and write treated as structurally different requests from the first line of a spec, not two branches of one function, because skipping that discipline is what lets a handler quietly accept a write with no value and pass something undefined to an actuator expecting a number.

None of this depends on Anthropic ever opening MHS beyond its current partner list. I would specify the same manifest discipline and the same double revalidation on a real installation today, using EXP_039 as the reference, regardless of which standard eventually governs the wire format.

I still do not know what the real MHS protocol looks like on the wire. I know what a capability manifest has to specify to be trustworthy, because I had to specify one myself.