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

With no annotations, description fully covers return format (list of moves with was→now, real date), ordering (newest-first), and two edge cases (untracked company returns covered: false, covered but no moves returns empty list). Doesn't mention auth or rate limits but is thorough for a read-only list tool.

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?

Two sentences, no redundant words. Front-loaded with the main purpose and ordering. Each clause adds unique value (was→now summary, real date, coverage behavior, empty list).

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 no output schema and no annotations, the description provides sufficient detail on return structure and edge cases. It doesn't explain error behaviors or rate limits, but for a straightforward list tool, it's nearly complete.

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?

Input schema already describes both parameters (competitor, limit) with full coverage. The description adds no new parameter-specific meaning beyond the schema; it only contextualizes the output. Baseline 3 is appropriate.

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?

Clearly states it lists 'recent tracked strategic moves for one competitor, newest-first'. Includes specific detail about output structure (was→now summary, real date) and edge cases (covered: false for untracked companies, empty list for no moves). Distinguishes from siblings like 'find_competitors' and 'get_competitor_moves_diff' by specifying it's for a single competitor.

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?

Implied usage for a single competitor; description explains behavior for untracked companies and empty results, helping the agent decide when it's appropriate. Lacks explicit alternatives but the sibling context and the 'for one competitor' phrasing provide guidance.

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