Skip to main content
Glama

reachy_move_antennas

Move the robot's antennas to specified positions by setting left and right angles in degrees, with optional duration for timed motion.

Instructions

Move the robot's antennas to specified positions

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
leftNoLeft antenna position in degrees
rightNoRight antenna position in degrees
durationNoMovement duration in seconds (default: 0.5)

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

B3.4/5.0
Behavior2/5

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, but it only says 'move' without explaining behavior such as whether movement is absolute or relative, whether the robot must be awake first, whether the command blocks until completion, or what happens if a position is out of range. This is a significant gap for a physical motion 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 a single clear sentence with no redundant wording. It is front-loaded with the action and resource, making it easy for an agent to parse quickly.

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

Completeness2/5

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

Given the absence of annotations and output schema, the description should provide more context about preconditions, side effects, or expected results. The schema covers parameters well, but the tool lacks guidance on whether the robot must be awake, whether the movement is safe to call anytime, or what the agent should expect in response, leaving the context incomplete.

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?

Schema description coverage is 100%, so the input schema already documents left, right, and duration with units and defaults. The description adds no new parameter semantics beyond the phrase 'specified positions', which is acceptable but does not elevate the score above the baseline.

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

Purpose5/5

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

The description states a specific verb ('move') and resource ('the robot's antennas'), making the tool's function immediately clear. It also distinguishes itself from sibling tools like reachy_move_head by targeting antennas specifically, not the head or other parts.

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 resource name implies this tool is for antenna movement, and sibling tools handle other body parts, so usage is inferable. However, there is no explicit guidance about when to use this tool versus alternatives like reachy_move_head, nor any mention of exclusions or prerequisites that would strengthen routing.

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