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

With no annotations, the description carries the burden, and it does disclose the return contract (ratio 1-21 plus AA/AAA pass status) and that large=true changes the verdict. It omits edge behavior such as invalid hex input, but for a side-effect-free computation this is solid disclosure with no contradictions.

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 tight sentences, front-loaded with purpose and return value, then the one non-obvious parameter rule and the disambiguation note. Nothing is padded, though the sibling clarification is thinner than it could be.

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 must explain returns — and it does (ratio range plus AA/AAA outcome). Parameters are fully covered by the schema. Complete enough for a simple read-only check tool, with only minor gaps around invalid input handling.

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 baseline is 3. The description restates the large=true threshold semantics that the schema already documents ('True if text is >=18pt or 14pt bold') and adds no new format or validation detail for foreground/background.

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: 'Check whether a foreground color is legible on a background color per WCAG 2.x contrast ratios.' It also positions itself as 'the legibility axis, separate from color-blindness,' which routes away from simulateColor. It does not, however, disambiguate from the arguably closer sibling checkPalette, so sibling differentiation is partial.

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 rather than stated: the tool is for contrast/legibility checks, and the color-blindness aside implicitly tells the agent when NOT to reach for it. There is no explicit 'use X instead when Y' rule, and the overlap with checkPalette is left for the agent to infer.

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

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

With no annotations, the description carries the full burden and does so well: it discloses the pipeline (dominant color extraction, protan/deutan/tritan simulation, pair-collapse detection), the severity-ranking behavior (area coverage so big-region conflicts outrank specks), supported formats (PNG/JPEG), and a non-obvious optional behavior (returnSimulated). It does not describe error modes (e.g., unreadable file, unsupported format) or how the returned conflict list is shaped.

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 purpose, then behavior, then input modes, then the caveat — a sensible information hierarchy. Every clause carries information (simulation types, area-weighted ranking, formats, caveat); nothing is padding.

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 5-parameter, zero-required tool with no output schema, the description covers what it does, what it accepts, and roughly what it returns (flagged pairs with area coverage). Gaps are minor: no statement about behavior when neither path nor dataUri is supplied, no error handling, and no note that the output conflicts are ranked.

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 baseline is 3. The description adds only modest value beyond the schema: it explains the path-vs-dataUri choice ('pass path for a local file, or a base64 dataUri') and clarifies that returnSimulated yields the recolored image itself. maxColors and the simulateType enum are left entirely to the schema.

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 concrete verb + resource (check an image's colors for color-vision-deficiency safety) and enumerates accepted artifacts (image, chart, screenshot, mockup), which implicitly separates it from the palette-oriented siblings checkPalette/generateSafePalette. It never names an alternative tool, so the differentiation from checkContrast/simulateColor is left to inference.

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?

Gives clear operating context (screening rendered images for CVD conflicts) and a useful scope boundary: 'A screening aid, not a legal (ADA/WCAG) audit.' It does not, however, route the agent to a specific sibling — e.g., checkContrast for WCAG ratios or checkPalette for raw palettes — so the when-to-use-this-vs-that decision is only implied.

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

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

With no annotations, the description carries the full burden, and it delivers: it names the exact simulations run (protanopia, deuteranopia, tritanopia) and the output behavior (flags collapsing pairs). It does not detail the return format or severity scoring, but the mechanism of analysis is unusually well disclosed for a tool without annotations.

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?

Two tight sentences: the first states the purpose, the second describes the mechanism and output, and a final clause bounds scope. Every clause earns its place with no repetition or cruft.

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 one required parameter fully documented in the schema, no output schema, and no annotations, the description provides enough for correct invocation: what it checks, how, and what the results mean. The absence of return-value details is a minor gap for a screening tool but not a blocker.

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% and the single parameter is already documented with examples in the schema. The description adds no parameter-level details beyond implying that colors are checked as a group. Baseline 3 is appropriate when the schema completely handles parameter documentation.

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 states a specific verb (check) and resource (a set of colors), and names the exact property it evaluates: distinguishability under color-vision deficiency. It also distinguishes itself from siblings like checkContrast (which measures luminance contrast, not CVD) by naming the simulations it runs.

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 gives clear context for use (screening a palette for colorblind safety) and explicitly bounds the scope with 'not a legal accessibility (ADA/WCAG) audit,' which routes users needing compliance to checkContrast or another sibling. It lacks an explicit alternative tool recommendation, but the boundary is well-communicated.

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

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

With no annotations, the description carries the full burden and does reasonably well: it discloses the optimization objective ('staying as close to the originals as possible'), the mechanism ('separated in lightness'), the rationale for that axis, and the three-part return payload. It stops short of stating behavior for already-passing inputs, single-color inputs, or whether output is deterministic.

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, front-loaded with the transformation and its guarantee, then the mechanism, then the return description. No filler and no repetition of the title.

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?

There is no output schema, so the description correctly compensates by enumerating what comes back (new colors, per-color movement, pass/fail status). Combined with the stated optimization goal and axis of separation, an agent has enough to call and interpret the tool; only edge-case behavior is unaddressed.

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?

Only one parameter and schema description coverage is 100%, so the schema already documents 'colors' with a hex example. The description adds no additional format or constraint detail (e.g., accepted color notations, array length limits), which matches the baseline of 3 when the schema does the heavy lifting.

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?

Specific verb (fix/adjust) applied to a specific resource (a color set that fails colorblind-safety), and the description implicitly separates it from siblings like checkPalette (diagnose only) and generateSafePalette (create from scratch). The phrase 'take a set of colors that fails... and return an adjusted set' makes the input contract and transformation unmistakable.

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 implies a precondition (input must be a failing set), which gives some usage context, but it never names an alternative or states when to prefer fixPalette over generateSafePalette or checkPalette. Usage must be inferred from the sibling names rather than the text.

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

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

With no annotations, the description carries the full burden and does real work: it discloses the seeding strategy (Okabe-Ito), the behavior above eight colors ('safely extended'), and a hard output invariant ('Never returns an unsafe color'). It still omits determinism (is the same count reproducible across calls?) and the ordering/format of the returned colors.

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, each earning its place: the output contract first, the implementation guarantee second, the trigger third. No restatement of the title or filler.

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 single-parameter, annotation-free tool with no output schema, the description covers the guarantee, the seed basis, and the call trigger, which is enough to invoke it correctly. The remaining gap is the return shape (array of hex strings) and reproducibility, which the agent must infer.

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 the baseline is 3, but the description adds genuine meaning beyond the schema's bare '1..24' range by explaining what happens to the count above eight colors. It still does not clarify behavior at the 24 cap or whether counts map to a fixed ordering.

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+resource ('Return N colorblind-safe hex colors') and immediately defines the guarantee that distinguishes it: distinctness under protanopia, deuteranopia and tritanopia. The generative verb separates it from the sibling verbs (checkContrast, checkPalette, fixPalette), so an agent can route without opening any 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?

Gives an explicit trigger: 'Use when asked for accessible / colorblind-safe / colorblind-friendly colors for a chart, plot, map or UI.' That covers the when-to-use side well, but it never states when NOT to use it or names the sibling to prefer for related tasks (e.g., verify an existing palette with checkPalette / fixPalette).

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

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

No annotations are provided, so the description carries the full burden. It discloses the input domain (single hex color, one of three deficiency types) and the general nature of the result, but says nothing about the output representation, whether results are approximate, or that the operation is side-effect free.

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?

A single front-loaded sentence with zero filler; the verb, scope, and accepted inputs all land immediately.

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?

With no output schema, the description should clarify the return shape (e.g. resulting hex or RGB triplet), which it does not. It is otherwise adequate for a simple two-parameter pure function.

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% and both parameters are already documented with enum and example format in the schema. The description restates the three enum values and the hex format without adding syntax, defaults, or edge-case behavior beyond the schema.

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: returning how one hex color appears under a named color-vision deficiency. It is clearly distinguishable from palette/contrast siblings by scope (single color simulation). Sibling differentiation is implicit rather than explicit, so not a 5.

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?

No guidance on when to pick this over checkContrast, checkPalette, or generateSafePalette, and no prerequisites stated. Usage is only inferable from the phrase 'single hex color'.

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