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

With no annotations, the description carries full burden. It discloses what each validation returns ('percentile, the corpus median/p25/p75 and a verdict') and includes concrete examples. It implies read-only behavior but doesn't explicitly state non-destructive intent, so a 4 is appropriate.

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 moderately long but every sentence adds value: purpose, usage, examples, and interpretation. It is front-loaded with the core function and maintains clarity without unnecessary verbosity.

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 7 optional parameters, no output schema, and no annotations, the description covers the main context well: what the tool does, how to use it, what it returns, and how to interpret the verdicts. It could mention edge cases like passing no parameters or invalid ranges, but overall it is solid.

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 0%, so the description must compensate. It conveys that parameters are design metrics (px, ms) and provides examples, but it doesn't enumerate or explain each of the 7 parameters. The parameter names in the schema are self-explanatory, but the description doesn't fully detail units or typical ranges beyond examples.

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: 'Grade YOUR design values against the measured corpus' with a specific verb and resource. It distinguishes itself from sibling tools by focusing on validation/checking design metrics against real product data, not fetching or comparing components.

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?

Explicit use case is provided: 'Use this to anti-slop-check your own output BEFORE shipping'. It also explains how to interpret results (p25-p75 normal, sub-p10/over-p90 needs reason), giving clear guidance on when and how to leverage the tool.

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