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

Annotations already declare readOnlyHint=true, so the agent knows this is a safe read operation. The description adds that the tool 'Returns a labeled strategy card to help shift your perspective and break through blocks,' which gives some context about the output format and purpose. However, it doesn't disclose details like whether the result is truly random, whether repeated calls can return the same strategy, or any rate limits. With annotations covering the safety profile, a 3 is appropriate – the description adds some value but not rich behavioral context.

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 concise and front-loaded with the core function. The first sentence states what it does, the second gives usage context, and the third lists trigger keywords. The final sentence about the return value is slightly redundant with the first sentence but adds useful context. No wasted words, though the structure could be slightly tighter.

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?

For a parameterless, read-only tool with no output schema, the description is quite complete. It explains what the tool does, when to use it, and what it returns. The only minor gap is that it doesn't specify whether the 'random' selection is truly random or if there's any weighting, and it doesn't describe the exact structure of the 'labeled strategy card.' However, given the tool's simplicity, these are minor omissions.

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 tool has 0 parameters, so the schema is trivially complete. The description doesn't need to explain parameters. The baseline for 0 params is 4, and the description adds value by explaining what the returned strategy card is for, which is more than enough for a parameterless tool.

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's function: 'Get a random Reduce strategy.' It names the specific resource (Reduce strategy) and the verb (get), and the sibling list shows other category-specific tools, so the purpose is unambiguous. The description also lists trigger keywords like 'simplify, subtract, remove, clarify, focus on essentials,' which further distinguishes it from siblings.

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 explicitly states when to use this tool: 'Use when overwhelmed by complexity, dealing with too many options, or when clarity is needed.' It also provides a clear list of use-case keywords. While it doesn't explicitly name alternatives, the sibling tools are category-specific, and the description's trigger words make the selection criteria clear. The 'Best for cutting through noise and finding the core' adds practical guidance.

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