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

With no annotations, the description carries the full burden. It discloses that the tool returns findings with reasoning and a concrete fix, and implies a non-mutating audit role. It could explicitly state that it does not modify the CSS, but nothing is misleading.

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 with no filler. The concrete tells are front-loaded, followed by the output behavior and when to run it. Every sentence earns 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 one-parameter tool with no output schema, the description fully covers what to pass, what will be checked, what the return looks like, and when to use it. No critical information is missing for selecting and invoking the 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?

The input schema already documents the single parameter at 100% coverage, including accepted forms (stylesheet text, design-token block, Tailwind config) and the instruction to paste the real thing. The tool description adds no additional parameter-level meaning, so the baseline of 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 ('Audit'), a clear resource ('CSS'), and enumerates concrete tells it detects. It clearly differentiates from sibling tools by evaluating existing CSS rather than generating palettes, fonts, or type scales.

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 workflow instruction: 'Run this before calling any UI finished', which tells the agent when to invoke it. It does not explicitly contrast with sibling tools, but the evaluative role is evident from the description.

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 key behavior: the output is 11 steps, contrast against white and black is precomputed, and CSS custom properties are included. It does not discuss side effects or edge cases, but the operation is described as a pure return, so nothing is misleading.

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, substantive sentences: what it does, what it returns, and when to use it. There is no filler and no repetition of schema fields.

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 two-parameter generator, the description covers the operation, color space, number of steps, contrast behavior, output artifacts, and the alternative to avoid. The explicit return summary compensates for the lack of an output schema.

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 reinforces that a seed colour drives generation, but it does not add format or default details beyond what the schema already provides.

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 names the exact operation ('Build a perceptually even colour ramp') and method ('from one seed colour, in OKLCH'). It clearly identifies this as the palette-generation tool among siblings and even contrasts it with hand-picking hex values.

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 gives explicit context: use this instead of hand-picking hex values, which produce uneven ramps. However, it does not explicitly mention sibling-tool exclusions such as suggest_pairing or check_contrast.

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 provided, the description carries the full burden, and it delivers key behavioral details: values are generated as clamp() functions, they interpolate continuously with viewport size rather than stepping at breakpoints, and the narrow end deliberately uses a gentler ratio for readability. It does not state whether the tool writes files or returns raw code, but for a build/generation tool the output is reasonably characterized as 'clamp() values.'

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 tightly written sentences deliver the core purpose, output format, behavioral model, and a design rationale without any filler. The most critical information — what is built and in what form — is front-loaded.

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 six-parameter tool with no output schema, the description gives enough to invoke it correctly: it names the output form (clamp() values) and explains the scaling behavior. It stops short of describing the exact return structure (e.g., custom properties vs. raw strings), which is a minor gap, but an agent can safely call it with defaults and understand what it will produce.

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?

The input schema covers all six parameters and their defaults, so the description does not need to repeat parameter mechanics. It does add useful context by explaining why the ratio behaves gently at the narrow end and why the scale is viewport-interpolated, but it does not enrich understanding of specific parameters like base_rem or steps_up 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?

The description opens with a specific verb and resource: 'Build a fluid modular type scale as clamp() values.' It further clarifies the output and behavior ('interpolate with the viewport instead of stepping at breakpoints'), distinguishing it from a static breakpoint-based type scale and from sibling tools like suggest_fonts or build_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 intended use case is implied through 'fluid modular type scale' and 'interpolate with the viewport' — an agent can infer this is for responsive typography. However, it never explicitly states when not to use it or names an alternative sibling, so the routing decision is left to inference rather than direct guidance.

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 discloses what the tool returns (WCAG 2.2 ratio, AA/AAA verdicts, APCA Lc) plus a limitation of WCAG 2.x on dark themes. It omits minor details like how large-text exceptions are handled, but is otherwise transparent.

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 well-structured sentences with no filler. The action and resource are front-loaded, and the APCA caveat is placed after the primary output description where it adds useful context.

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 check with no output schema, the description names both output families and provides a meaningful usage caveat. The main gap is not specifying whether AA/AAA verdicts assume normal text, large text, or both, but this is minor for a simple scoring 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%, and both parameters are already described clearly in the schema, including accepted color formats via 'same formats'. The description adds little beyond the pair concept already implied by the parameter names.

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?

Uses a precise verb ('Score') and object ('foreground/background pair'), then names the concrete metrics returned. This clearly distinguishes it from generation-oriented siblings like suggest_pairing and build_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?

Provides clear context: the tool is for evaluating a specific color pair, and the APCA note gives actionable guidance for dark themes. It does not explicitly name sibling alternatives or exclusions, but the intended use is unambiguous.

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 provided, the description carries the transparency burden. It discloses meaningful behavior: results come from the live catalogue of ~1,950 families and defaults are deliberately excluded unless opted in. It does not discuss output shape, determinism, or network/auth expectations, but for a read-only suggestion tool the main behavioral traits are surfaced.

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, no filler; the primary action and scope are front-loaded, and the default-exclusion behavior earns its place as meaningful nuance.

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 tool with fully documented optional parameters, the description covers the source and filtering behavior, but with no output schema it leaves the return shape unmentioned and gives no guidance about sibling tools. It is adequate for a basic call, but an agent evaluating whether this is the right tool over suggest_pairing still has to infer from context.

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?

The input schema has 100% description coverage and clear descriptions for role, mood, limit, and include_defaults, so the baseline is 3. The description's default-exclusion sentence reinforces include_defaults but adds no new parameter semantics beyond what the schema already states; role and mood are merely echoed in the purpose sentence.

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 names the action ('Suggest'), the resource ('Google Fonts'), and the selection lens (role and mood), plus the live catalogue scope. It is distinguishable from the sibling suggest_pairing by focusing on individual faces rather than pairings, though it does not explicitly name the alternative.

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 use case: picking a single font for a role/mood while avoiding default-looking UI fonts. It does not state when to prefer a sibling like suggest_pairing, audit_css, or check_contrast, and includes no when-not-to-use guidance.

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 behavioral burden. It discloses the return format ('ready-to-use @import URLs and CSS stacks') and the underlying design principle ('the contrast reads as deliberate'), which is meaningful context. It does not mention whether multiple pairings are returned or address edge cases, but the core behavior is transparent.

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 single sentence packs the action, the design rationale, and the output format in one economical sentence without repeating schema fields. Every clause earns its place, and the key verb-resource pair is front-loaded.

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 one-parameter tool with no output schema, the description covers the purpose and the return value, and the schema covers the parameter. What is missing is an explicit statement of result count or the default behavior, but that is a minor gap. The description is adequately complete for an agent to invoke 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 coverage is 100%: the single 'mood' parameter already has an enum and description. The tool description only repeats the notion of 'a mood' without adding syntax, defaults, or interpretation details. Baseline 3 is appropriate because the schema does the heavy lifting and the description adds only a slight purpose linkage.

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 opens with a specific verb and resource: 'Suggest display-and-body font pairings for a mood.' It further specifies the design intent ('pairing across a category boundary so the contrast reads as deliberate') and the concrete deliverable ('Returns ready-to-use @import URLs and CSS stacks'). This clearly distinguishes it from the sibling suggest_fonts, which presumably suggests individual fonts rather than pairings.

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 a clear condition for use ('for a mood') but never states when to prefer this tool over suggest_fonts or when not to use it. The agent has to infer that pairings are the target output from the name and description; there is no explicit alternative routing or exclusion. This is implied usage at best.

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