Skip to main content
Glama
aj-dev-smith

duck-mcp

by aj-dev-smith

Point the head

duck_look
Idempotent

Set the head and neck orientation of a simulated duck robot in radians; the balance policy adjusts the body to compensate. Head position persists until you change it.

Instructions

Point the head (radians; caps ~±1.4 yaw, ±1.1 pitch, ±0.31 roll). This is a command to the balance policy, not a servo write — the body compensates. All zeros returns the head to neutral. The gaze intent is sticky — it holds between tool calls until changed.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
head_yawNo
head_rollNo
head_pitchNo
neck_pitchNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
okYes
rpy_degYesTrunk orientation [roll, pitch, yaw], degrees
sittingYes
uprightYesFalse once tilted past ~45 deg. There is no self-recovery policy: if the duck falls, use duck_reset.
vel_cmdYesCurrent sticky velocity intent [vx, vy, wz]
behaviorYesEpisodic trick currently running, else null
position_mYesTrunk world position [x, y, z], meters
sim_time_sYesSim clock, seconds. The sim runs in real time; this snapshot is stale on arrival.
ground_pickYes
vel_body_mpsYes
yaw_rate_rpsYesYaw rate, rad/s, counterclockwise positive
active_policyYesWhich ONNX policy is driving: standing, walking, sit, ground_pick, kick_left/right, roulade
ball_position_mNoBall world position [x, y, z], meters (ball scene only)
trunk_height_mmYesTrunk height above floor, mm (~116 standing)
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

It adds substantial behavior beyond annotations: the command is sticky and persists between calls, all zeros returns to neutral, and the body compensates rather than directly moving a servo. These details meaningfully shape how an agent should invoke and reason about the tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is compact—three sentences, each carrying distinct value: units/caps, policy behavior, and persistent-state behavior. It is front-loaded and free of filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description covers the main purpose and key behavioral traits, and an output schema exists so return values need not be described. Still, neck_pitch is absent, direction conventions are unclear, and interaction with sibling tools is not addressed, so an agent is left with material gaps.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 0% schema description coverage, the description compensates by providing units and approximate caps for yaw, pitch, and roll. However, neck_pitch is never mentioned, and sign/direction conventions are not explained, leaving an important parameter underspecified.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool points the head and gives units and range caps, which is specific and useful. It does not explicitly differentiate from sibling tools like duck_camera or duck_drive, though the resource ('head') is unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives important context: it is a command to the balance policy, not a servo write, and the body compensates. However, it does not name alternatives or give explicit when-to-use vs. when-not-to-use guidance relative to sibling tools.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/aj-dev-smith/microduck-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server