This server provides a safe, simulation-only MCP interface for managing a two-arm Seeed reBot hardware setup.
Discover devices — list available arms (e.g. rebot-dm, rebot-rs), their slots, physical metadata, and safety limits.
Read device state — query a device's state, joint positions, enabled status, or emergency-stop state.
Write device slots — send position updates or other slot writes; dry-run by default, with real motion only when apply=true and confirmed=true and actuators are enabled.
Emergency stop — immediately latch an E-stop and disable the selected arm.
Plan two-arm handoff — generate a dry-run plan for object transfer between arms; never moves real hardware.
Enforce safety constraints — joint changes are limited (e.g. 0.15 per step), E-stop overrides motion, and all operations confirm safety before applying.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@rebot-mhs-lab List all discovered reBot devices and show their emergency stop status"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
以 Seeed reBot 双机械臂为第一套参考硬件，探索安全、可复现、模型无关的 AI-to-hardware 接口。
清乐智能 · Physical AI for Science — 访问项目网站
这是一个面向两台 Seeed Studio reBot 机械臂的安全起步项目。它先把 Anthropic 已公开介绍的 MHS 核心概念——设备发现、统一 read/write、自然语言硬件描述、设备级安全限制——做成可运行的仿真，再通过 MCP 暴露给 Claude、DeepSeek Harness 或其他智能体。
当前状态：MHS-ready prototype，不是官方 MHS 实现。 截至 2026-09-01，MHS 仍是申请制研究预览，规范与 SDK 尚未公开。拿到官方预览后，计划只替换协议/驱动适配层。
本仓库是独立社区研究项目，与 Anthropic、DeepSeek AI、Seeed Studio 或 Hugging Face 没有隶属或背书关系。
Related MCP server: RoboDK MCP Server
自动发现 reBot Arm B601-DM 和 reBot Arm B601-RS 两台虚拟设备。
读取设备状态、标准化关节位置、使能状态和急停状态。
所有写操作默认 dry-run，不会移动机械臂。
运动必须同时满足：未触发急停、已显式使能、apply=true、confirmed=true。
单次关节变化限制为 0.15，越界命令在 driver 层拒绝。
生成双臂物体交接计划，但当前永远只做 dry-run。
单臂 bring-up：组装、供电、电机 ID、零点和急停。先用 MotorBridge 单独验证每个关节。
LeRobot 接口：理解 connect → get_observation → send_action → disconnect，完成 Leader/Follower 遥操作。
数据闭环：录制一个简单任务、回放、检查数据，再训练 ACT/SmolVLA 等策略。
MHS 设备层：把关节状态、动作、物理属性和安全边界变成可发现的设备 slot。
MCP 编排层：让智能体读取状态、生成计划和调用受限动作；高速控制仍由 LeRobot 策略或确定性代码完成。
双臂 Demo：先做仿真交接，再做真实双臂标定、碰撞区和人工确认。
不要一开始就训练 VLA，也不要让大模型逐帧直接输出电机控制。第一阶段的目标是一个可靠、可复现、随时能急停的控制链路。
cd /Users/dave/Desktop/physical_ai
uv sync --extra dev --python 3.12
uv run pytest
uv run mcp dev server.pyMCP Inspector 打开后，可以依次调用：
discover_devices
read_device(device_id="rebot-dm", slot="state")
write_device(device_id="rebot-dm", slot="position", value={"shoulder_pan": 0.1})
plan_two_arm_handoff(from_device="rebot-dm", to_device="rebot-rs")
第 3 步没有传入 apply=true，因此只返回预演结果。
也可以把本地 stdio server 接入支持 MCP 的宿主：
{
"mcpServers": {
"rebot-mhs-lab": {
"command": "uv",
"args": [
"run",
"--directory",
"/Users/dave/Desktop/physical_ai",
"python",
"server.py"
]
}
}
}DeepSeek Harness 已提供官方 MCP client 插件，因此第一阶段不需要直接修改 Harness。我们把本仓库作为独立 MCP hardware server，通过 @deepseek-ai/dsh-mcp-client 接入。示例配置位于 .dsh/cordis.patch.yml。
npx @deepseek-ai/dsh webDeepSeek Harness 仍处于 developer preview，插件版本应与宿主版本保持一致。详细步骤和后续原生插件路线见 docs/DEEPSEEK_HARNESS.md。
当前电脑是 Apple Silicon Mac，适合运行本项目、MCP 和仿真。
B601-DM 未来可通过串口桥/MotorBridge 接入，但 Seeed 的完整 LeRobot 教程以 Ubuntu 物理机为主。
B601-RS 的 follower 教程使用 SocketCAN；真实控制建议放在 Ubuntu 22.04 或 Jetson 上，而不是直接放在 Mac 上。
推荐架构：Mac 运行 Claude/MCP 客户端，Ubuntu/Jetson 贴近机械臂运行 driver；两者通过受限的网络接口通信。
目前的 SimulatedArmDriver 只提供三件事：
discover() 设备能力、物理属性、安全限制
read(slot) 状态读取
write(slot, value) 带设备级校验的写入官方 MHS SDK 可用后，新建 OfficialMHSReBotDriver 实现同样的行为，把现有 MCP 工具和双臂编排保留下来。真实 LeRobot 适配器则把标准化状态映射到 get_observation() / send_action()。
固定底座、清空工作区并准备物理急停。
初次调试保持至少一米距离，限制速度、扭矩和单步变化。
禁止带电插拔电源或信号线。
断电、掉线或反馈异常后，先停止程序并重新回零，不能从旧状态继续。
真实运动不得沿用示例中的标准化位置；必须根据各自校准数据、关节限位和碰撞模型生成。
仓库目前公开用于审阅、学习和讨论，但尚未选择开源许可证。在许可证正式确定之前，请不要假定拥有复制、修改、分发或商业使用本代码的权利。这样可以在创业项目早期保留专利、双许可证和商业授权的选择空间。
Discover the available arms, their slots, physical metadata, and safety limits.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It does communicate the kind of information returned (arms, slots, physical metadata, safety limits), which suggests a read-only discovery operation, but it does not explicitly state that it has no side effects, requires no capabilities, or behaves differently from read_device. This is adequate but not fully transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, information-dense sentence with no filler. Every phrase contributes meaning: it names the action, the target resource, and the categories of information returned.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that there are no parameters and an output schema exists to describe return values, the description covers the essential purpose well. It could be more complete by explicitly noting that this is a non-mutating discovery step that should precede device operations, but for a zero-parameter tool this is a minor gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and an empty input schema, so there are no parameter semantics to document. The baseline of 4 applies here; the description does not need to explain parameters that do not exist.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Discover') and identifies the resource ('available arms') plus the key output dimensions ('slots, physical metadata, and safety limits'). This clearly distinguishes the tool from siblings like read_device, write_device, emergency_stop, and plan_two_arm_handoff by signaling an enumeration/discovery role.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies that the tool should be used to enumerate available hardware before operating on it, but it never explicitly states when to use it versus alternatives or mentions that it is a prerequisite for read_device or write_device. Usage context is present only by inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Latch the emergency stop immediately and disable the selected arm.
| Name | Required | Description | Default |
|---|---|---|---|
| device_id | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It says the tool latches and disables, which is some behavioral information, but it does not disclose consequences such as whether the action is reversible, whether it affects other devices, whether confirmation is required, or what happens after the stop. For a safety-critical emergency stop tool, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no filler, front-loading the imperative action ('Latch the emergency stop immediately') before the affected resource. Every word contributes, making it highly economical and scannable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a high-stakes emergency stop tool with no annotations and only minimal parameter documentation, the description is too terse. It omits the relationship between device_id and the arm, any safety disclaimers, and when this tool should be invoked relative to the sibling tools. An output schema exists, so return-value details are less critical, but the missing operational and selection context leaves the description incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the only parameter, device_id, has no description beyond its type and title. The description mentions 'the selected arm' but never explicitly maps device_id to an arm or explains how to obtain a valid device_id. The description does not compensate for the schema's lack of parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('Latch the emergency stop') and a specific resource ('the selected arm'), which clearly distinguishes it from the sibling tools like read_device, write_device, and plan_two_arm_handoff. The word 'emergency' conveys urgency and scope. Even without title or annotations, an agent can tell what this tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool versus alternatives, no prerequisites, and no mention of when not to use it. It does not explain how emergency_stop differs from write_device in terms of use cases, nor does it reference discover_devices for resolving device_id. Usage context is left entirely to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Build a dry-run plan for a two-arm object handoff; never moves hardware.
| Name | Required | Description | Default |
|---|---|---|---|
| to_device | No | rebot-rs | |
| from_device | No | rebot-dm |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden and directly states the key side-effect boundary: 'never moves hardware.' This is valuable transparency for a tool in a family that includes write_device and emergency_stop. It doesn't describe output details, but an output schema is present, so that omission is acceptable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One sentence with no wasted words; the core purpose is front-loaded and the critical safety qualifier follows immediately. It is concise without being under-specified.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with two optional parameters and defaults, this description gives the essential purpose and non-mutation guarantee; an output schema covers return-value details. The only meaningful gap is lack of parameter explanations, but defaults minimize the risk of calling it wrong.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description never explains to_device or from_device or their defaults. 'Two-arm handoff' plus the self-explanatory parameter names add some context, but the description does not compensate for the absent schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb-resource pair: it builds a dry-run plan for a two-arm object handoff, and adds a distinguishing safety qualifier ('never moves hardware') that separates it from sibling write/control tools. The purpose is not a tautology and is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this tool is for planning a handoff without executing it, but it never explicitly states when to choose it over siblings like write_device or emergency_stop, nor does it mention alternatives or exclusions. Usage context must be inferred from 'dry-run plan'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read a device slot: state, position, enabled, or emergency_stop.
| Name | Required | Description | Default |
|---|---|---|---|
| slot | No | state | |
| device_id | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of disclosing behavior. It clearly indicates a read-only operation, which implies no mutation, and it lists the admissible slot values, adding scope boundaries. However, it does not disclose potential error conditions, permission requirements, or behavior when the device is unavailable, though the output schema may cover return structure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence that front-loads the action and resource, then efficiently lists the acceptable slot values. Every word contributes, with no fluff or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with two parameters and an output schema present, so the description is largely sufficient. The only potential gap is the ambiguity between reading the emergency_stop slot and the separate emergency_stop sibling tool, but the verb 'Read' mitigates this and indicates no triggering behavior occurs.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It does explain the 'slot' parameter by enumerating its possible values, which is essential and absent from the schema. It does not elaborate on 'device_id', but the parameter name is self-explanatory, and the description as a whole makes the tool's semantics understandable.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Read'), names the resource ('a device slot'), and enumerates the exact slot values it can read: state, position, enabled, or emergency_stop. This clearly separates it from mutating siblings like write_device and emergency_stop, and from discover_devices which enumerates devices.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is only implied through the verb 'Read' and the sibling names, suggesting it is for inspecting device slots rather than writing or triggering emergency stops. There is no explicit statement of when to choose this tool over write_device or emergency_stop, nor any exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Write one device slot.
Calls are dry-run by default. Applying motion requires enabled actuators plus both apply=true and confirmed=true. Emergency stop always disables motion.
| Name | Required | Description | Default |
|---|---|---|---|
| slot | Yes | ||
| apply | No | ||
| value | Yes | ||
| confirmed | No | ||
| device_id | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. It discloses the non-obvious dry-run default, the gating conditions for actual motion, and the safety override from emergency stop—valuable knowledge that is not inferable from the schema alone.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three short sentences with purpose front-loaded. Every sentence contributes behavioral or safety context, and there is no redundant or filler content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a five-parameter write operation with no annotations and 0% schema coverage, the description covers the critical dry-run and motion-application semantics but omits what a 'slot' is, how 'value' should be structured, and when to prefer this tool over its siblings.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It adds meaningful semantics for apply and confirmed by tying them to dry-run behavior and motion application, but the required parameters device_id, slot, and value are not explained beyond their names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The opening line 'Write one device slot.' states a specific verb and resource, and it matches the tool name. It is distinguishable from siblings like read_device and emergency_stop, though the meaning of 'slot' is left somewhat undefined.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear contextual conditions: calls are dry-run by default, and applying motion requires enabled actuators plus apply=true and confirmed=true. However, it does not explicitly mention when to use this tool over the listed alternatives or state exclusions, so the usage guidance is implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.0discover_devicesemergency_stopplan_two_arm_handoffread_devicewrite_deviceScored across 5 tools
Each tool has a clearly distinct purpose: discovering metadata, reading state, writing state, triggering an emergency stop, and planning a two-arm handoff. There is no meaningful overlap that would cause an agent to select the wrong tool.
Most tool names follow a clear verb_noun pattern: discover_devices, read_device, write_device, plan_two_arm_handoff. The exception is emergency_stop, which is a noun-style command rather than a verb-prefixed action, making the set slightly inconsistent.
Five tools is a well-scoped size for this robotics lab server. Each tool covers a distinct operation and none feel redundant or extraneous.
The tool set covers device discovery, state reading, state writing, safety shutdown, and handoff planning. Minor gaps exist around explicitly executing a planned handoff or resetting a latched emergency stop, but these may be intentionally handled outside the MCP surface or through write_device.
Read-only finance and operations controls for AI agents with evidence and safe next actions.
The trust harness for AI agents. Set what an agent can do before it acts.
Control real Android and iOS devices with LLM agents — tap, swipe, type, automate flows.
Robot embodied-AI cloud for GPU training, inference, benchmarks, and robot data collection.
