The Reachy Mini MCP server exposes only a single tool, 'operate_robot', which is a meta-dispatcher that accepts arbitrary tool_name strings and parameters. This violates fundamental tool design principles. The tool has a generic name that does not follow verb_noun conventions. The description exists but is vague ('Meta-tool that dispatches to individual robot operations by name') and does not clearly explain WHEN to use it, WHAT operations are supported, or what the expected return structure is. The input schema is present but severely underspecified: 'tool_name' is a free-form string with no enum constraint, 'parameters' is an object with no shape documentation, and 'commands' is an array with no item schema. No output schema is documented. The tool is designed to hide actual robot operations behind a string dispatcher, forcing LLMs to reason about opaque tool names and parameter structures without any discovery mechanism or validation. This pattern (single meta-tool dispatcher) is actively harmful to agent reasoning and violates the single-responsibility principle.

• CRITICAL: Refactor the server to register EACH robot operation as a separate, named MCP tool with its own description and input schema. Instead of 'operate_robot' with tool_name='move_head', expose 'move_head', 'rotate_antenna', etc. directly. Load tool definitions from tools_repository at startup and register them as individual FastMCP tools using the @mcp.tool() decorator. This enables proper LLM tool discovery and reasoning.
• For each robot operation tool, establish a concrete verb_noun naming convention: 'move_head', 'rotate_antenna', 'capture_image', 'play_animation', etc. Ensure the name alone conveys what the tool does.
• Write a 50 - 200 character description for each tool explaining: (1) what action it performs, (2) when to call it (prerequisite context), (3) example input/output. Example: 'move_head - Move the robot's head to a target position (x, y, z in meters). Use after checking current position with get_head_position. Returns success status and final coordinates.'
• For each tool parameter, add a JSON Schema description field stating: (1) parameter purpose, (2) valid range/format/enum values, (3) example values (but do NOT include example values in the description itself, use 'enum' or 'pattern' schema properties instead). Example schema: {'type': 'number', 'description': 'Head X position in meters (range: -0.5 to 0.5)', 'minimum': -0.5, 'maximum': 0.5}.
• Document the output schema for each tool, specifying: (1) return type (object/array/scalar), (2) field names and types, (3) example output. If a tool returns success/failure, include a 'success' boolean and 'error_message' string for failures.