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

Annotations already declare readOnly/openWorld=false/destructive=false, so the safety profile is covered. The description adds genuinely non-obvious behavior: the component type is inferred from the name, comparisons are against convention-based expected sets (not hard rules), and output is a list of redlines worth requesting.

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 purpose, then input formats with an example, then what gets compared, then the limitation. Dense but every clause carries information; the enumerated component-type list is long yet bounds scope usefully.

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, but the description indicates the return is a list of gaps and redlines. Input formats, inference logic, comparison dimensions, and the paste-only limitation are all covered, leaving only minor gaps (e.g., output shape granularity).

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 100%, so baseline is 3; the description goes beyond it by documenting the JSON object shape ({name, states, sizes, tokens, behaviours, notes, redlines}) and giving a concrete pipe-delimited example line. This meaningfully supplements the terse schema description.

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 ('Checks a design handoff list for gaps') and immediately scopes what 'gaps' means: states per inferred component type, sizes, token categories, and behaviors. An agent can distinguish this from narrower siblings like check_state_coverage or check_touch_targets because the scope is spelled out.

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?

Clear operating context: you paste a spec (JSON or pipe-delimited lines) and it audits handoff completeness, with an explicit caveat that it 'sees only what you paste, not the design file.' It does not name alternatives or state when not to use it (e.g., vs check_state_coverage), so it falls short of full routing guidance.

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