Claude Has Turned a Robotic Arm into Its Own Hand

Anthropic is looking for a “body” for Claude.

On August 28, Anthropic announced a hardware-oriented interface standard called Model Hardware Standard (MHS). Its goal is not to put Claude inside one particular robot, but to enable the model to discover, understand, and call cameras, robotic arms, microscopes, and laboratory instruments from different manufacturers.

In an earlier demonstration, Claude used a robotic arm to stop a $50 million transfer. That case was more of an attention-grabbing safety demonstration, but it represented a very real shift: the model was no longer merely telling humans, “This transaction is risky.” Through connected physical devices, it could perform an action to block, isolate, or confirm the transaction.

This is also the most noteworthy aspect of Anthropic’s release. Claude is beginning to evolve from an “Agent that can call software tools” into an “Agent that can call real-world devices.”

MHS: A “Tool Protocol” for the Hardware World

If MCP can be understood as a universal socket connecting models with software tools, then MHS is more like a socket connecting models with physical devices.

In the past, an Agent that wanted to control a robotic arm typically needed an adapter written specifically for a particular brand and model. That adapter had to handle the manufacturer’s proprietary protocol, device state, coordinate systems, control commands, and error responses. Switching to another robotic arm might require rewriting an entire set of integration logic. The problem is even more apparent with laboratory equipment such as microscopes, cameras, centrifuges, and liquid-handling workstations: each often has its own software, drivers, and data formats, making direct coordination between devices difficult.

MHS attempts to hide these differences behind a standard interface. Once connected, a device needs to describe several categories of information to the Agent:

• Device capabilities: What data it can read and what actions it can perform;
• Real-time status: Whether it is currently idle, running, malfunctioning, or locked by a human operator;
• Physical properties: The robotic arm’s workspace, joint ranges, payload capacity, and end-effector type;
• Safety boundaries: Which actions require confirmation, which areas cannot be entered, and which parameters cannot exceed their limits;
• Operation results: Whether an action succeeded, what observations the device returned, and what can be done next.

This means Claude does not have to treat every piece of hardware as a completely unfamiliar API. The model can first read the device description, plan actions based on the task, and then adjust its next steps according to the real-time status returned by the device.

From an engineering perspective, the value of MHS is not that it suddenly gives large models the ability to perform motion control. Rather, it reduces the system-integration coupling cost of connecting models to hardware. In the past, a robotics project was more like writing a closed program for one machine. MHS attempts to turn robots, instruments, and sensors into a collection of tools that an Agent can discover dynamically.

How Claude Controls the SO-ARM101

According to Anthropic, after being connected through MHS, Claude can call the low-cost SO-ARM101 robotic arm from the Hugging Face LeRobot ecosystem. The process does not require a specialized policy to be trained for this robotic arm in advance, nor does it depend on teleoperation or human demonstrations.

Claude first measures the arm’s workspace and performs basic calibration, then uses MHS to call the underlying controller and execute actions. The model does not directly output a sequence of “joint angles.” Instead, it first understands the device’s capabilities and boundaries, then converts a natural-language task into executable steps.

This differs significantly from the traditional embodied-intelligence approach.

The traditional approach typically requires collecting large amounts of robot trajectory data so that the model can learn, “Given this scene, how should I move?” This approach can be highly efficient with fixed hardware and fixed tasks, but changing the device, end effector, or operating environment often requires retraining or fine-tuning.

MHS takes a different path: it makes the hardware’s capabilities, status, and constraints as explicit as possible, allowing Claude to handle higher-level task understanding, planning, and decision-making, while the device controller handles low-level motion execution.

This can be compared to hierarchical control in autonomous-driving systems: the large model is more like the driver responsible for “Where am I going? What situation am I facing now? What strategy should I take next?” The low-level controller handles the steering wheel, brakes, and motors, ensuring that actions do not exceed mechanical or safety limits.

This division of labor does not mean that large models have solved robot control. It merely changes the problem from “The model must remember how every machine moves” to “Can the model correctly understand device descriptions, plan actions, and handle errors during execution?” The latter problem remains difficult, but it is easier to address through standardized interfaces and engineered safety-control layers.

From Transfer Risk Control to Laboratory Automation

The $50 million transfer demonstration showed the potential of MHS in high-risk operations.

If a banking system detects an abnormal transaction, an Agent can first call the account system to read the transaction status, then call a risk engine to determine the cause of the anomaly. When the system requires physical isolation, human review, or an emergency disconnect, the Agent can go further and operate a connected robotic arm, button, or actuator to prevent the transaction process from continuing.

Of course, a real financial system cannot hand the final decision on whether to block a transfer to a model that can act freely. A more reasonable architecture would be for the model to identify risks and make recommendations, for a rules engine to determine permissions, for the hardware control layer to execute authorized actions, and for humans to remain in the loop at critical points.

The real value lies in the fact that MHS connects software decisions with physical execution. In the past, even if an Agent discovered a risk, it could only send a message, create a ticket, or call a software interface. Once connected to physical devices, it can pull an emergency stop, close a valve, isolate a sample, or prevent a process from entering an irreversible stage.

This capability is even more natural in laboratory settings.

The case demonstrated by Anthropic involved coordination among microscopes, cameras, and control devices. For example, researchers may need to track a moving cell over an extended period. Previously, staff might have had to continuously monitor the microscope feed and manually adjust the stage, focus, and camera parameters whenever the target moved out of view.

If all these devices can be described and called through MHS, Claude could continuously perform a closed-loop sequence of operations based on visual feedback:

1. Read the current image from the microscope and camera;
2. Determine the target cell’s position and direction of movement;
3. Adjust the stage or lens to keep the target centered in the field of view;
4. Adjust the focus, exposure, and sampling frequency based on image quality;
5. Record the experimental state, pausing and requesting human intervention if the target is lost or a device malfunctions.

This is not simply about “letting AI control a robotic arm.” It is about allowing multiple devices to coordinate around a single experimental objective. A robotic arm, microscope, camera, and sample-processing device could potentially be combined temporarily by the same Agent into an experimental workflow.

Anthropic describes this form as a kind of “distributed embodiment”: Claude does not need to be permanently bound to one robot. Any device that conforms to the standard and has a software control layer could become one of its body parts for a particular task.

Several Hurdles Remain Before It Is Truly Usable

The concept behind MHS is elegant, but several key issues remain before it can be deployed at scale.

First, a Device Description Does Not Equal Device Reliability

Giving a model knowledge of a robotic arm’s operating range does not mean it can reliably determine grasping positions in a complex environment. The real world contains occlusion, reflections, deformation of soft objects, sensor drift, and communication latency. If a model converts an incorrect visual judgment into a physical action, the consequences may be far more serious than those of an incorrect text response.

Therefore, MHS must work alongside deterministic safety controllers. The model can propose, “Move the sample to position B,” but collision detection, speed limits, payload assessment, and emergency-stop mechanisms should not be handled by a language model alone.

Second, Could the Model Misinterpret High-Risk Instructions?

Tasks such as “block the transfer,” “close the valve,” and “stop the experiment” may appear clear, but in practice they all involve permissions, timing, and context. A model might correctly understand the literal instruction while failing to recognize that the device is currently under maintenance or that an action could trigger a chain reaction.

It is not enough for MHS to define only “read” and “write” interfaces. Device descriptions also need to include permission levels, reversibility, approval requirements, and risk assessments. For irreversible actions, the default should be simulation first and confirmation afterward, rather than allowing the model to execute them immediately.

Third, Can the Standard Achieve Genuine Cross-Vendor Compatibility?

The hardware world is more fragmented than the software world. Different manufacturers define precision, coordinate systems, status codes, and error handling differently. Even if everyone adopts MHS, whether device descriptions are sufficiently accurate and control commands remain consistent will still require long-term ecosystem validation.

The hardest part of a standard is often not writing the protocol, but getting enough hardware manufacturers to follow it and continue supporting it through device firmware, SDKs, and after-sales maintenance.

Claude’s Approach Differs from That of Robotics Companies

The current competition in embodied intelligence can roughly be divided into two approaches.

One is a vertically integrated approach led by robotics companies: building everything in-house, from hardware, sensors, and data collection to policy models, with the goal of achieving reliable operation in specific environments such as warehouses, factories, or homes. This approach offers tighter control over task boundaries and a clearer path to commercialization.

The other is the general-purpose Agent approach demonstrated by Anthropic: the model does not necessarily have a fixed body, but instead calls different devices through standard interfaces. Its strengths are generalization and composability, allowing multiple systems to be connected. Its weaknesses are greater dependence on the quality of device descriptions, environmental feedback, and safety governance.

Claude may not outperform specialized robot policy models on every low-level motion-control task. Millisecond-level robotic-arm control, collision avoidance, and high-precision grasping should still be handled by specialized controllers. But general-purpose models have greater advantages in tasks such as “understanding an ambiguous objective, calling multiple devices, and dynamically adjusting the workflow based on the results.”

In other words, Anthropic may not be competing for control of the robots themselves, but for the task-orchestration layer above robots and laboratory equipment. If MHS can develop into an ecosystem, Claude could become an entry point to the operating system of the physical world.

What This Means for Developers

For developers, the most important lesson from MHS is not to immediately buy a robotic arm, but to rethink how hardware is integrated.

Traditional hardware integration has generally focused on “What commands does the device support?” Hardware interfaces designed for Agents also need to answer, “What is the device’s current state?” “Which actions are risky?” and “How can the completion of an action be verified?” Hardware manufacturers need to provide more than drivers. They also need to provide a machine-readable capability description and a safety contract.

When building a similar system, developers should consider at least the following:

• Separate high-level task planning from low-level motion control;
• Provide observable results for every action instead of returning only success or failure;
• Require approval and human confirmation for high-risk or irreversible actions;
• Establish a unified error-handling and fallback mechanism for device states;
• Support simulation, previews, and dry-run modes before real execution;
• Maintain complete audit logs for every instruction issued by the model;
• Apply least-privilege access by default to prevent the Agent from gaining unnecessary device control.

This approach also applies to industrial automation, warehouse robots, smart homes, and medical devices. Once models truly enter the physical world, prompt safety is no longer the whole problem. Permission management, fault recovery, and boundaries of responsibility become equally important.

Conclusion: The Real Competition Is Shifting from “Can It Do It?” to “Can It Do It Safely?”

The most noteworthy aspect of Claude controlling a robotic arm through MHS is not how impressive the demonstration itself looks, but that Anthropic is attempting to establish a new relationship between software and hardware: models are no longer confined to chat windows or a particular application. They can treat real-world devices as discoverable, composable, callable tools.

This approach has not yet proved that it can solve industrial-grade reliability problems, nor has it shown that general-purpose models can replace robot policy models. But it has identified a key bottleneck in the commercialization of physical AI: there are too many hardware devices, their interfaces are too fragmented, and integration is too expensive, while Agents need an ecosystem of devices they can understand and call dynamically.

If MCP solves the question of “how models use software,” then MHS is attempting to answer the question of “how models use the real world.”

Claude has not truly taken control of the physical world, but it has begun trying to connect the world’s devices to its own toolbox. What determines whether this approach can move beyond a demo is not whether the robotic arm can move, but whether it can stop before moving incorrectly, and whether it can tell humans why it moved, what it moved, and who had the authority to make it move.

Sources

• Hugging Face LeRobot: Public documentation for low-cost robotic hardware such as the SO-ARM101 and the LeRobot software ecosystem, providing background on the robotic-arm control discussed in this article.
• LeRobot GitHub repository: An open-source robot learning and control project maintained by Hugging Face, providing information on related hardware, data, and policy toolchains.
• Anthropic GitHub organization: Anthropic’s public developer projects and tooling portal for readers interested in following the progress of its Agent and tool-calling ecosystem.