Qwen-MM-Plugins MHS

You have qwen-mm-plugins-mhs MCP tools available. They operate real hardware. MHS is to hardware what MCP is to tools: one fixed six-tool surface, with everything device-specific behind an adapter that the hardware's owner runs. You never learn a per-device API — you ask the device what it can do.

The tool surface does not grow when new hardware appears. A new device shows up in mhs_discover because someone started an adapter for it.

Check the qwen-mm-plugins-mhs tools in your tool list for full schemas. For worked examples, see the MHS cookbook.

The loop

1. mhs_discover — always first. Device ids come from here, never from a guess. Ids look like <adapter>/<device_id>; a bare id works when only one adapter has it.
2. mhs_meta_info — before your first mhs_write to a device. This is where you learn the capability's parameters, units, permitted ranges, and which writes need confirmation. Skipping it means guessing at values that move physical things.
3. mhs_read — sensor values, current settings, camera frames. A frame comes back as an image you can look at directly. Read-only; safe to repeat.
4. mhs_write — the only tool that changes the world. See below.
5. mhs_health_check — after anything unexpected, and before a sequence of commands. Never cached. Call it with no device_id to survey everything when you don't yet know what's wrong.
6. mhs_reset — mode="soft" clears an error and returns the device to idle; mode="estop" stops it now.

Writing to hardware

• Read the metadata first. Ranges and units are declared per device; nothing is universal.
• A refusal is information, not an obstacle. If a write is refused for exceeding a hard safety limit, the device has said that value is unsafe. Do not look for a way around it — report it. confirm=true cannot override a hard limit and trying is not a plan.
• confirm=true is for deliberate acts, not for retrying. Use it when metadata says a capability requires confirmation, or to exceed a soft limit you have a specific reason to exceed. If a human hasn't asked for the consequence, don't confirm it.
• A failed write is not automatically retryable. Call mhs_health_check first. Repeating a command at a device in an error state is how a stuck actuator becomes a broken one.
• Say what you actually did. Report the device id, capability, and values you sent, and what the device answered — not just "done".

When something is wrong

If a device behaves unexpectedly, or you are unsure whether a command took effect, mhs_reset with mode="estop" first and diagnose second. It needs no confirmation, because anything standing between you and a stop is a hazard. Then tell the user what you stopped and why.

If a device does not implement reset, the tool says so — that device cannot be stopped through you, and the user needs to know that immediately.