PickShade color tools

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds real value beyond that by disclosing the breadth of the audit: contrast tiering (body/large/decoration), CVD confusion detection, and out-of-sRGB flagging. It does not describe the response shape, but that is a minor gap given the read-only nature.

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 sentences, front-loaded with the action verb and a tight comma-separated enumeration of checks, followed by a single usage directive. No filler or redundant restatement of the name.

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 carries the burden of conveying what comes back, and it does so reasonably by naming the classifications (safe for body/large/decoration, CVD-confusable pairs, out-of-sRGB colors). It stops short of describing structure or severity detail, but an agent has enough to call it and interpret the intent.

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% and the single 'colors' parameter is thoroughly documented with accepted formats and a 2-12 count. The description adds nothing about parameters, so the baseline of 3 is correct when the schema does all the work.

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 ('Check') and resource ('every text and background pair in a palette') and enumerates the exact analyses performed (WCAG 2, APCA, CVD, sRGB gamut). This clearly separates it from siblings like check_contrast, simulate_cvd, and check_gamut, which each do a subset.

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 final sentence gives clear timing guidance ('Use it before shipping a theme or chart palette'), which is meaningful context for when to reach for this tool. However, it never names alternatives or exclusions, so an agent must infer whether to prefer this over check_contrast or simulate_cvd for narrower tasks.

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?

Annotations already declare readOnlyHint=true and openWorldHint=false, and the description is consistent with that (it computes and exports, it does not persist). It adds useful behavioral detail beyond annotations: exactly what artifacts are produced and that a contrast audit is included. It stops short of describing return shape or limits, which keeps it off a 5.

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 that opens with the core action and then lists outputs; no filler or repetition. The dense enumeration is justified by the tool's breadth, though the run-on form makes it slightly harder to scan than a short multi-sentence layout.

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 carries the return-value burden and does so well by naming every deliverable (scales, theme roles, four export formats, contrast audit). The remaining gap is that it does not clarify how optional color inputs (accent, neutral, secondary) affect the output when omitted.

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 57%, and the description meaningfully expands the 'format' enum by naming Tailwind v4, CSS variables, shadcn/ui globals.css and DTCG tokens, plus the 50–950 scale structure. It says nothing about name, primary, secondary, accent, neutral or the 'values' enum, leaving several parameters documented only in 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?

Specific verb ('Build') plus a precisely scoped resource ('full color system from a brand color'), enumerating the 50–950 scales, five color families, theme roles, export formats and the contrast audit. This scope clearly separates it from narrow siblings like generate_palette, generate_scale and export_tokens.

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 by the breadth of the output (a whole system rather than one palette), so an agent can infer it is the heavyweight option. However, it never states when to prefer this over generate_palette/export_tokens or any prerequisite, so no explicit guidance is given.

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?

Annotations already establish this is a safe read-only, closed-world operation. The description adds real behavioral value beyond that: it discloses both compliance frameworks reported (WCAG ratios with AA/AAA thresholds split for normal vs large text, APCA Lc value and allowed usage level) and that a hue-preserving passing text color is suggested.

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, front-loaded with the primary action and framework coverage before the secondary suggestion behavior. Every clause carries information and nothing is padded.

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 carries the return-value burden and does so well by enumerating ratios, AA/AAA levels, APCA Lc, and the suggested color. Only the accepted color input formats are unspecified, which leaves a small gap.

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 both parameters (text/foreground color, background color) are already documented in the schema. The description adds no accepted color syntax or format detail beyond that, so the baseline 3 applies.

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 (check) and resource (text contrast against a background) and names the two standards evaluated, WCAG 2 ratio/AA/AAA plus APCA Lc and usage level. It is less clear how it differs from the sibling fix_contrast, since it also advertises suggesting a passing text color.

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 only implied by the metrics named – an agent can infer this is the tool for evaluating whether a foreground/background pair passes WCAG or APCA. No explicit when-to-use, no prerequisites, and no routing against siblings like fix_contrast, check_gamut, or compare_colors.

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?

Annotations already establish a safe, closed-world read (readOnlyHint=true, openWorldHint=false). The description adds real behavioral content beyond that: it discloses the mapping algorithm (CSS Color 4 gamut mapping in OKLCH) and the preservation guarantees of the fallback (lightness and hue kept), which tells the agent what to expect from results.

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 dense sentence that front-loads the primary operation (gamut check across three spaces) and appends the fallback behavior. No filler or repetition.

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 must carry return-value meaning, and it does describe both outputs: per-gamut fit and a lightness/hue-preserving sRGB fallback. It stops short of specifying the exact result shape (e.g., booleans per gamut), which is a minor gap for a simple one-parameter tool.

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% — the schema already enumerates accepted formats (#ff5733, rgb(), hsl(), oklch(), names, Tailwind classes) in detail. The description adds no parameter-level information beyond that, so baseline 3 applies.

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 (check) and resource (color gamut fit across sRGB, Display P3, Rec. 2020) and adds the secondary output (closest sRGB fallback). This clearly separates it from siblings like check_contrast and convert_color, which do different color checks.

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 when to use it — when you need to know if a color is out of gamut and want a printable/displayable fallback — but it never names alternatives or states exclusions (e.g., 'use convert_color to change color space'). Usage is inferable rather than guided.

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?

Annotations declare readOnlyHint and openWorldHint, so the safety profile is covered. The description adds some value by listing the computed metrics, but doesn't say anything about determinism or precision limits.

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?

One dense sentence front-loaded with the verb and the main metric, then the ancillary outputs. Efficient, though the comma-heavy enumeration is slightly hard to parse.

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?

A pure computation tool with readOnly annotation, full schema coverage, and no output schema. The description adequately covers inputs, outputs, and safety context; only the verdict thresholds and contrast definition are left unstated.

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 already carry rich format examples (hex, rgb, hsl, oklch, names, Tailwind), so the schema fully documents them. The description adds nothing beyond the names 'first'/'second'. Baseline 3.

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 (Compare) and resource (two colors), and the description enumerates the outputs (CIEDE2000, deltaE OK, verdict, lightness/chroma/hue shifts, contrast) that distinguish it from siblings like check_contrast or convert_color.

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?

Implies usage by enumerating what it computes, but never states when to call this instead of the sibling check_contrast or nearest_names. No explicit alternatives or exclusions are given.

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?

Annotations declare readOnlyHint=true and openWorldHint=false, so safety is covered. The description adds that values follow CSS Color 4, which is useful behavioral context about accepted syntax. It does not mention default formats beyond the schema, output shape, or error behavior, so it remains adequate rather than rich.

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 sentences: one states the operation and format set, the second adds the CSS Color 4 standard. No waste, front-loaded, easy to scan.

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?

The tool is simple with only two params and full schema coverage, so the description is nearly sufficient. It could note the default format set or error conditions for invalid input, but those are minor omissions for a read-only conversion tool.

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 parameters are fully documented in the schema, giving a baseline of 3. The description adds the format family list and the CSS Color 4 standard, which clarifies accepted value syntax beyond the schema's examples, nudging this to 4.

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 (convert) and resource (a color between formats), and enumerates the format set. Among siblings like parse_color, mix_colors, and check_gamut, this is clearly the format-transformation tool.

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 usage (you have a color and want other formats) but gives no explicit when-to-use vs. parse_color or check_gamut. Nothing routes the agent away from misusing this when it actually wants parsing or gamut checking.

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?

Annotations already declare readOnlyHint=true and openWorldHint=false, so safety is covered. The description adds one genuinely useful behavioral fact — unnamed colors are auto-named to the closest color name — but omits the 24-color cap, default format/value behavior, and what the output looks like.

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 dense sentence front-loaded with the action and an efficient enumeration of formats. No waste, though the long comma list slightly reduces scannability.

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?

A 3-parameter export tool with no output schema, so the description should clarify what gets returned (file contents? string?) and format-specific behavior. It covers formats and auto-naming but leaves the return shape and default values (css/oklch) unexplained.

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 only 33%: the color field is well documented but format, values, and the name field lack in-schema descriptions. The description compensates weakly by listing formats (css, tailwind, scss, json, dtcg, array, svg), but does not explain the 'values' enum or the name field's role, leaving gaps at this coverage level.

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 (export/turn into) and resource (colors to code) plus an exhaustive list of output formats. Clearly distinguishes itself from siblings like generate_palette, convert_color, nearest_names; the agent knows this produces code artifacts, not analyses or generated color sets.

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 by naming the output formats, but the description never states when to pick this over nearest_names (for naming) or convert_color (for single conversions). No exclusions or alternative guidance, so the agent must infer from format names alone.

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 annotations readOnlyHint=true and openWorldHint=false, the safe, closed-world read nature is already declared. The description adds the search scope (English, Russian, 30k extended names) but doesn't disclose other behavioral traits like rate limits or exact return format. It's adequate given the 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?

The description is a single, well-structured sentence that front-loads the core purpose and supporting details without any redundancy or fluff.

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 the tool has no output schema and only 3 parameters with 67% schema coverage, the description provides enough context about what it searches and returns (HEX values). It could mention the limit/result format, but otherwise it's sufficient for an agent to call 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 description coverage is 67%, so some parameters (limit, locale) lack schema descriptions. The description mentions searching in English and Russian, which adds meaning to the 'locale' parameter. Examples like 'sage' clarify the 'query' parameter. This compensates for the coverage gap.

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 provides a specific verb ('search') and resource ('color names'), and distinguishes itself from the sibling 'nearest_names' by focusing on searching names by keywords rather than finding closest names to a color. It explicitly states it returns HEX values, making the purpose unambiguous.

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: use it to turn a description into real colors, with examples like 'sage' or 'бордовый'. It implies the tool is for name-based lookup, but does not explicitly state when to use alternatives like 'nearest_names' or 'parse_color'.

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?

Annotations already declare readOnlyHint=true and openWorldHint=false, and the description adds genuinely useful behavioral context: the fix preserves hue and character by mutating only OKLCH lightness, which tells the agent what the transformation will and won't do. It does not describe the shape of the returned result, but with a safe read-only profile the bar is lower.

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 sentences, front-loaded with the core mechanism before the target enumeration. The target list is long but each entry earns its place by decoding the enum; no filler sentences.

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 4-parameter, read-only, no-output-schema tool, the description covers the operation, the adjustable inputs, and the full target vocabulary. The only mild gap is that it doesn't state what the response contains (presumably the adjusted color pair), but no output schema exists to make that omission costly.

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 only 50%, and the description compensates well by spelling out what each target enum value actually means numerically (aa = 4.5:1, aaa = 7:1, apca-body = Lc 75, etc.) and by explaining that 'adjust' selects text vs background. The two color parameters are already documented in 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 (find/fix) plus the exact mechanism: the closest color reaching a contrast target, achieved by changing only OKLCH lightness. This is sharply distinguishable from siblings like check_contrast (measures) or audit_palette (bulk audit), which an agent can infer without opening schemas.

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 when to use it (a color pair fails a contrast requirement and needs remediation) and clarifies that either text or background may be adjusted. However, it never explicitly contrasts itself with check_contrast or audit_palette, nor states when not to use it.

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?

Annotations declare readOnlyHint=true and openWorldHint=false, covering the safety profile. The description adds useful behavioral detail: the deterministic seed behavior ('pass a seed to get the same palette every time') and that 'keep' colors are preserved. However, it doesn't describe output format or the meaning of the mode styles beyond naming them.

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?

One efficient sentence that front-loads the core purpose (generate a harmonious palette in OKLCH) and packs the parameters into a compact clause. Slightly dense but nothing wasted.

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 4-parameter tool with no output schema and no annotations conflict, the description covers the essentials but omits output shape, what the 'auto' mode does, and how 'size' interacts with 'keep'. Adequate but with clear gaps given no output schema to carry return-value documentation.

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 50%, with 'keep' and 'seed' well-documented in the schema but 'mode' and 'size' lacking descriptions. The description names the mode options (matching the schema enum) and re-states the seed determinism, but adds no semantics not already in the schema. Baseline 3 given the mixed 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 (generate) and resource (harmonious palette in OKLCH), and lists the modes and seed behavior. It's clearly distinguishable from siblings like generate_scale, harmonies, or tint_shades because it's the palette generator with a mode/style system.

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 when to use it (generating a new palette, optionally preserving existing colors via 'keep'), but doesn't explicitly say when to use generate_palette vs siblings like generate_scale or harmonies, nor any prerequisites. Usage is implied rather than stated.

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?

Annotations already declare readOnlyHint=true and openWorldHint=false, so safety is covered; the description adds real behavioral detail beyond them by naming the color space (OKLCH), the interpolation goal (even perceived lightness steps), and the exact output shape. It stops short of describing error handling for unparseable colors or the return format of each step.

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?

One sentence that front-loads the action and output, then qualifies it with color space and intent. No filler, no redundancy with 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 carries the burden of explaining results, and it does so adequately by specifying the 11 stop values and Tailwind-like shape and by disclosing the OKLCH/lightness rationale. Minor gap: it does not say what concrete value type is returned per step (hex, object, token name).

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?

With a single parameter and 100% schema description coverage, the schema already exhaustively documents accepted color formats with examples, so the baseline is 3. The description only reinforces that a single seed color is expected and adds no syntax or format detail 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: build an 11-step tint/shade scale from one color, with explicit stop values (50, 100 … 900, 950) and the Tailwind-palette shape. It is clearly a single-input scale generator, though it never names or contrasts the closest siblings (tints_shades, generate_palette).

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 'from one color' phrasing implies when this tool applies (single-seed scale generation), but there is no explicit when-not guidance nor any named alternative such as generate_palette or tints_shades. Usage must be inferred from the input requirements.

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?

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description goes beyond them by disclosing the computational basis — OKLCH with even lightness — which is a genuine behavioral trait that shapes what the returned colors look like.

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 sentence, front-loaded with the verb and resource, then the computation method, then the enumerated outputs. No filler and nothing that fails to earn its place.

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 simple read-only tool with full schema coverage, the description covers purpose, method, and output categories. The only gap is the shape of the return value (e.g. whether each harmony is a list of color strings), which is not described and there is no output schema to fall back on — minor for this tool class.

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 both parameters (color formats, kind enum with 'all harmonies when omitted') are fully documented in the schema. The description's enumeration of harmony names merely restates the enum and adds no syntax or semantics beyond it; baseline 3 applies.

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 (get) and resource (color harmonies) and enumerates the eight harmony types it computes. This distinguishes it cleanly from siblings like generate_palette, mix_colors, and tints_shades without needing to open a 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 only implied by the purpose statement — the agent can infer it is for deriving a harmony set from one base color. There is no explicit when-to-use, when-not-to-use, or pointer to a sibling (e.g. generate_palette) that might overlap, so an agent must guess at the boundary.

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?

Annotations declare readOnlyHint and openWorldHint=false, so the safety profile is covered. The description adds behavior beyond annotations: it returns modern CSS, a fallback with precomputed stops, and the stop colors, plus notes the OKLab gray-middle avoidance. It doesn't mention rate limits or error conditions, but for a pure computation tool that's less critical.

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 sentences, front-loaded with the core action and output, then a useful color-space note. Efficient with little waste, though the OKLab note could be folded in more tightly.

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, read-only computation tool with no output schema, the description covers purpose, output shape, and a key behavioral trait (fallback generation). Missing only explicit when-to-use guidance versus siblings.

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 60%, with enums documented and some parameter descriptions present. The description doesn't add parameter syntax or format details beyond the schema's own color examples and stop counts. Baseline 3 applies because the schema does most of 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?

Clear verb+resource: builds a CSS gradient with named interpolation spaces. Sibling tools are all color-utility functions, but the description doesn't explicitly differentiate from e.g. convert_color or mix_colors, though the gradient output makes it fairly distinct.

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 when to use OkLab vs sRGB for gradients, but does not state when to use this tool versus alternatives like convert_color or mix_colors. No explicit exclusions or alternatives are given.

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?

Annotations declare readOnlyHint and openWorldHint, so safety is covered. The description adds valuable behavioral context: OKLab keeps the middle bright while sRGB tends to turn gray, and it returns a ready color-mix() expression. This exceeds bare annotation coverage, though it doesn't discuss error handling or edge cases.

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 two concise sentences that front-load the core purpose and add a useful color space note. It avoids redundancy, though the color space behavioral note could be more tightly integrated.

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 the tool's simplicity (4 params, no output schema), the description covers purpose, a key behavioral nuance, and return format. It's nearly complete, but lacks usage guidelines against sibling tools, which is a minor gap.

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 75%. The description mentions 'at a ratio' and 'in a chosen color space,' which maps to the amount and space parameters, but it doesn't clarify that amount is the share of the second color, nor does it enumerate acceptable color formats beyond what the schema already describes.

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 (Mix) and resource (two colors) with the ratio and color space dimensions, making the tool's function immediately clear and easily distinguishable from siblings like convert_color or generate_palette.

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?

It implies the tool is for blending colors but provides no explicit guidance on when to use it versus alternatives like convert_color or find_colors, nor any prerequisites or exclusions.

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?

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds real behavioral value beyond that: it discloses the ranking metric (perceptual distance deltaE OK) and the three name sources searched, which tells the agent what kind of result set to expect.

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 that states the action, the three result categories, and the ranking basis with no filler. Every clause carries information.

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 carries the return-value burden; it names the content categories returned but says nothing about result shape (name plus hex plus distance?) or how 'limit' bounds the output. Adequate for a simple lookup, but it leaves the response format to inference.

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%; the 'color' parameter is well documented in the schema with accepted formats and 'locale' has its own description, while 'limit' is undocumented but its bounds/default are self-evident. The description adds no parameter-level detail, so the baseline of 3 is appropriate.

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 ('Find') and resource ('closest named colors, CSS color keywords and Tailwind CSS classes') plus the direction of the lookup ('for a color'). The 'for a color' framing implicitly separates it from sibling find_colors/parse_color, which go name-to-color rather than color-to-name.

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 purpose implies the usage context (given a color, get its nearest names), but there is no explicit when-to-use statement, no when-not, and no naming of alternatives such as find_colors or convert_color. Usage is inferable but not stated.

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?

Annotations already declare readOnlyHint=true and openWorldHint=false, so safety is covered. The description adds the breadth of accepted input formats ('any color', CSS names, Tailwind classes) and the full output payload, but says nothing about failure modes for malformed colors or how the locale parameter affects results.

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 a colon-delimited list of returned facets; every item earns its place by telling the agent what it gets back. The list is long but not padded with 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?

With no output schema, the description must describe returns and does so thoroughly, covering every reported field. The remaining gap is behavioral rather than informational: no mention of invalid-input handling or how locale shapes the name output, both of which are low-stakes for a read-only converter.

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%, with the 'color' parameter enumerating every accepted syntax and 'locale' documenting its enum and default, so the schema carries the burden. The description only restates 'any color' and adds no format or locale semantics beyond that, making the baseline 3 correct.

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 ('read/describe') and resource (a color), then enumerates the exact facets returned: HEX/RGB/HSL/OKLCH, human name, Tailwind class, hue family, sRGB/P3 fit, and best text color. That enumeration implicitly separates it from narrower siblings like convert_color, nearest_names and check_gamut, though it never names an alternative explicitly.

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 opening 'Read any color and describe it' implies when the tool applies, but there is no explicit when-to-use/when-not-to-use statement and no routing to the overlapping siblings (convert_color, check_contrast, check_gamut, nearest_names). Guidance is inferable rather than stated.

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?

Annotations declare a read-only, closed-world operation, so the safety profile is covered. The description adds valuable specifics: Machado 2009 at full severity and the pair-confusion output. It does not mention limits on color count, encoding requirements, or the return shape, so it is adequate but not rich.

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 that names the verb, the resources, the scientific basis, and the secondary output. No filler or repetition.

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?

Covers the core operation and method, but with no output schema the description should say more about what is returned (simulated colors per kind, confusable pair list format) and about the colors input constraints. It is adequate rather than complete for a two-parameter simulation tool.

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 0%, so the description must carry parameter meaning. It names the four CVD kinds, which maps to the kinds enum, but says nothing about the colors parameter (accepted formats, limits, required). The schema itself documents colors thoroughly, leaving the description with limited added value.

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: simulating how colors appear under four named color-vision deficiency types, plus identifying confusable pairs. It clearly distinguishes itself from siblings like check_contrast or nearest_names, though the description leans on the technical term 'CVD' only in the tool name rather than in prose.

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 usage (show colors under CVD and find confusable pairs) but gives no explicit when-to-use guidance or contrast against alternatives like check_contrast. An agent must infer that this is the accessibility simulation tool from the sibling list.

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?

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds one genuinely useful behavioral fact not in structured data: the output is returned as HEX and values are evenly spaced. It does not disclose how many values come back or how 'steps' interacts with output volume.

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, front-loaded with the core operation and the output format, with the use-case hint appended. No filler or redundancy.

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 two-parameter read-only tool with no output schema, the description covers the output format (HEX) and typical use, which is decent. The remaining gap is the undocumented 'steps' parameter, whose meaning an agent must infer from the schema bounds alone.

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 only 50%: 'color' is well documented in the schema, but 'steps' has no description anywhere, and the tool description never explains that it controls the number of generated values or its 2-20 range. The phrase 'evenly spaced' gestures at it but adds no real semantic meaning over 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 (get) and resource (tints/shades/tones of a color) and even defines each term parenthetically, so the operation is unambiguous. However, it does not differentiate itself from close siblings such as generate_scale, mix_colors or harmonies, which an agent might otherwise reach for.

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 second sentence gives implied usage context ('Good for hover states, borders and backgrounds') but never states when to choose this tool over generate_scale or mix_colors, nor any prerequisites or exclusions. Usage is suggested by scenario rather than by routing logic.

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