microduck-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| DUCK_HOST | No | Host for the SSH transport (e.g., duck@microduck.local). Required when DUCK_TRANSPORT is 'ssh'. | |
| DUCK_TRANSPORT | No | Transport mode for the Microduck server: 'mock', 'sim', 'unix', or 'ssh'. Defaults to 'mock'. | mock |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| duck_healthA | Full hardware+software health report: battery (volts and percent), control-loop rate, servo/board temperatures, loaded policy, and whether the robot considers itself healthy. Read-only and always safe to call. Call this FIRST in any session, and again before any sequence of motion commands. |
| duck_versionA | The robot's name, serial and uptime (configd system.info). Read-only. |
| duck_updatesA | Installed daemon releases and which one is active/golden. Read-only. (Installing/rolling back is deliberately NOT exposed as a tool yet — see CLAUDE.md 'Deliberately excluded'.) |
| duck_monitorA | One robot.state frame: which policy is driving, the velocity requested vs applied (and what limited it), joints, gravity in the body frame (≈[0,0,-1] when upright — a large X or Y component means it has fallen), odometry, and the safety flags (fallen, limp, busy). Read-only and always safe to call. Use it to confirm a walk actually moved the robot, or to check posture before/after a behavior. For battery and temps use duck_health. |
| duck_cameraA | A still frame of what the duck sees or looks like right now, returned as a PNG image. view='head' is the robot's own head camera; 'follow' (default), 'front', 'side' and 'top' are third-person views around the robot. Read-only, never moves the robot. Available on the sim transport today; on hardware it will come from mediad's WebRTC stream (not wired yet) and the mock transport returns a placeholder. |
| duck_walkA | Send a velocity intent: vx forward m/s, vy sideways m/s, wz yaw rad/s. Values are clamped to ±0.25 m/s linear and ±1 rad/s yaw. Walks for duration_s (default 2 s, max 10 s) then stops; the call returns when the walk is over. duck_stop interrupts it at any time, and robotd's own deadman stops the duck if this server dies mid-walk — it does not run away. Call duck_monitor afterwards to see how far it got. Refused below 15% battery or when fallen. |
| duck_behaviorA | Trigger a named built-in behavior: sit, stand, getup (power the joints and rise to the home pose after a fall — on hardware a human rights the duck first; in sim it is set upright in place), pickup (beak to floor, grab), kick, roulade (forward roll), quack. sit/stand are no-ops if already in that posture. Scripted moves take 0.5–3 s; call duck_monitor to see when 'busy' clears. Battery- and health-gated like walking (quack is free). |
| duck_stopA | Immediately zero all motion intents. NEVER gated, never rate-limited — always available. Call this if anything looks wrong, if a human asks you to stop, or if you are unsure what the robot is doing. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 8 tools
The status tools (version, health, updates, monitor) overlap somewhat in being read-only system queries, but their descriptions clearly partition them into identity, health, software releases, and live robot state. Motion tools (stop, walk, behavior) and camera are unambiguous.
All tools share a consistent duck_ prefix and the names are short, readable, and predictable. The mix of noun-like names (duck_camera, duck_health) and imperative verbs (duck_stop, duck_walk) is a minor deviation rather than a chaotic convention.
Eight tools is well-scoped for a robot observation and control server: four read-only status/observation tools, three motion/behavior tools, and one emergency stop. Each tool has a clear purpose and none feel redundant.
The tool set covers the full intended workflow: inspect health and state, get a visual feed, command locomotion and behaviors, and stop in an emergency. The deliberate exclusion of update installation/rollback is documented and does not leave an operational gap for normal robot use.