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

Annotations already declare a safe read-only, closed-world operation, and the description stays consistent while adding substantial context: what the output contains, that the leading-wording check is a keyword heuristic, and that the five-user figures are convention rather than verified. The self-disclosed limits on the heuristics are exactly the kind of caveat annotations cannot express.

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?

Front-loaded with the action and the no-model-call constraint, then the input contract, then the return contents. It is dense but nearly every clause conveys real information; the closing sentence on provenance (Krug, Cooper, Norman) is the only part that could be trimmed.

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?

No output schema exists, so the description carries the full burden of describing returns, and it enumerates the screener, session outline, per-task checks, metrics, sample-size note with the formula, and note-taking sheet. For a six-parameter template tool this is sufficient for an agent to invoke it correctly.

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 coverage is 67% and the description compensates well, spelling out the accepted shapes for `participants` (number, criteria list, or {count, groups, profile}) and `tasks` (strings or {name, scenario, start, success}) plus the method enum values. `product` and `session_minutes` are only named, leaving the default-on-45 to the schema, so it stops just short of full coverage.

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?

States a specific verb and resource ('Build a usability test plan skeleton') and immediately scopes it as fixed template logic with no model call, which separates it from generative siblings. An agent can distinguish it from research-adjacent tools like usability_stats or tree_test_scorer without opening the schema.

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 is implied through the required inputs ('goal' = what you need to learn, 'tasks'), which frames the scenario well, but there is no explicit when-to-use/when-not or named alternative among the many sibling planning and stats tools. The agent must infer that this is the upstream planning step rather than an analysis step.

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