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

Annotations already carry readOnlyHint=true, and the description is consistent with a pure analysis tool. It adds genuine behavioral detail beyond the annotation: the verdict taxonomy (strong/viable/contested/collision), the 0-100 distinctiveness scale, and the fact that it consults archive context per colour. The provenance-based scoring caveat lives in the schema rather than the description, but the description discloses the core analytic behavior well.

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?

Three sentences with zero filler: purpose question, input summary, output list, usage timing, and replacement value. Dense but readable, and the most decision-relevant information (what it returns, when to use it) is front-loaded before the output enumeration.

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 complex tool with 7 parameters and an output schema, the description covers the essentials: purpose, inputs, outputs, and when to invoke. The presence of an output schema relieves the description of explaining return-value structure. Minor gaps: the meaning of 'archive context for each colour' is opaque, and the verified-vs-estimated provenance behavior is only in the schema — an agent reading only the description would miss a key scoring caveat.

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 100%, so the schema already documents all 7 parameters with examples (e.g., '#D4A829', 'UK luxury food retail', provenance enums). The description restates the input set at a summary level but adds no new semantic information beyond the schema. Baseline 3 is correct since the schema carries the full burden.

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?

Opens with a purpose-framing question ('Can this brand own this colour against these competitors in this market?') that captures the exact job. Enumerates concrete inputs and outputs (CIEDE2000 distance, distinctiveness score, ownership verdict) that clearly differentiate it from sibling tools like colour_compare or colour_metrics — this is an ownership/strategy assessment, not a numeric comparison.

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?

Provides explicit timing guidance: 'Use before committing to a brand colour in a competitive market.' Also states it 'replaces manual colour distance checks and competitor palette analysis,' which frames the decision context. However, it never names a sibling alternative or states when NOT to use it (e.g., when only raw CIEDE2000 numbers are needed), so it stops short of full exclusion guidance.

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