robot_control

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

With no annotations available, the description carries the full transparency burden. It does disclose some behavioral traits: 'intelligent routing', 'rich conversational responses', and 'consistent error handling and safety protocols across all robot types'. But it is mostly promotional and vague—there is no mention of side effects, what happens on failure, software requirements, whether actions require confirmation, or how physical safety is enforced. The description is not contradictory, but it gives only partial transparency.

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

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

The description is far too long for an agent-facing tool definition. The PORTMANTEAU PATTERN RATIONALE section explains internal design philosophy rather than how to call the tool, and the SUPPORTED OPERATIONS list duplicates the action enum that is already in the schema. While the description uses headings and bullet formatting, many sentences (e.g., 'Follows FastMCP 2.13+ best practices') do not help an agent invoke the tool correctly.

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

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

Given the tool's complexity (23 parameters, 40 actions, many robot types), the description is incomplete: the SUPPORTED OPERATIONS section omits at least six actions that appear in the schema's `action` enum—`start_cleaning`, `stop_cleaning`, `clean_room`, `go_to`, `get_map`, and `start_fast_mapping`. It also fails to map which parameters are required for specific actions, leaving the agent to infer or scout a large parameter space. The presence of an output schema helps, but the gap between the narrative operations and the actual enum is a meaningful completeness error.

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

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

The input schema already provides 100% parameter description coverage, including descriptions for every action enum value and ranges for velocity, water/suction levels, and coordinates. The description mostly restates or duplicates this information (especially the SUPPORTED OPERATIONS list) without adding actionable param semantics beyond what the schema already provides. Per the baseline, 3 is appropriate when schema does this heavy lifting.

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

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

The description clearly states this is a 'Unified robot control' interface and lists the exact platforms it supports ('Dreame D20 Pro', 'Yahboom', 'Moorebot', 'Unitree', 'virtual robots'). It is more specific than the name alone and conveys it is an aggregation tool. However, it does not explicitly differentiate from siblings like robot_virtual, dreame_control, or drone_control, so the boundary of what this tool owns vs. those tools is inferred rather than stated.

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

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

The description explains why a consolidated tool exists ('Instead of creating separate tools for each robot type...') and what robot types it supports, which implies when to use it. However, it never says 'use this instead of X' and does not list exclusions or conditions that would route the agent to sibling tools such as dreame_control, drone_control, robot_behavior, or robot_virtual. There is no practical guidance for selecting between this and the many sibling tools that appear to overlap in purpose.

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