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

Even without annotations, the description reveals important behavioral traits: keyword does substring, case-insensitive, non-fuzzy matching; Chinese and English result sets may not overlap; multi-word queries are not AND-split; category values are exact with no aliases; market intelligence entries are hidden by default; and inventory metrics are intentionally not hardcoded to avoid drift. This goes far beyond a basic tool statement.

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 only three sentences, front-loads the purpose, and contains no redundant fluff. Every sentence contributes either to core functionality, scope, or a note about data freshness.

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?

The description covers return summary fields, category scope, behavior of each parameter, and points to external sources for inventory metrics. However, it states '10 个品类' (10 categories) while the schema enum includes 11 values (including connectors, flexible_actuators, etc.), creating a factual mismatch that could mislead an agent. No output schema exists, but the summary field list partially compensates.

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?

Schema description coverage is 100%, so the baseline is 3. The description text adds no additional parameter-specific meaning beyond what is already in the schema's parameter descriptions. The only extra context is the note about inventory metrics, which is not parameter-related.

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 the tool 'searches robot components' with specific filters (category/keyword) and explicitly notes it returns summary entries (id/name/category/manufacturer/specs/evidence level). This distinguishes it from the sibling tool get_component_detail, which presumably returns full details.

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?

Usage context is implied through the description of search behavior and parameter guidance (e.g., keyword matching, category exact match), but there is no explicit mention of when to use this tool versus alternatives like get_component_detail or check_compatibility. No exclusions or 'when not to use' guidance is provided.

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