Skip to main content
Glama

CSS contrast pairs

css_contrast_pairs
Read-only

Extracts real foreground and background color pairs from CSS instead of guessing roles from token names. Pass a public url (the page, its style blocks and up to 12 linked stylesheets are fetched) or paste css (and optionally html for its style blocks). For every rule that sets color, it finds the background set by the same rule, by an ancestor named in the selector, or by body/html, resolves var() custom properties, light-dark() and prefers-color-scheme / [data-theme] / .dark variants, and applies opacity. Returns WCAG ratio, APCA Lc, the threshold (large text 3, otherwise 4.5), file and line for each failing pair, a list of thin margins, a list of pairs whose background is assumed (only the page root or the browser default was available), and text over images or gradients that cannot be computed. Optional scheme (both, light, dark) and viewport (width in px for min-width/max-width media queries, default 1280). Reads CSS only: no rendering, inline style attributes, script, or text over photographs.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "css_contrast_pairs"
  }
}

Input Schema

NameRequiredDescriptionDefault
cssNoCSS source to check.
urlNoA public page URL to fetch.
htmlNoOptional HTML whose <style> blocks are read.
schemeNoWhich color scheme to evaluate. Default both.
viewportNoViewport width in px for width media queries. Default 1280.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / scheme / description
      Previous value: -"Which colour scheme to evaluate. Default both."New value: +"Which color scheme to evaluate. Default both."
  2. Added

TDQS

A4.6/5.0
Behavior5/5

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

Goes well beyond the readOnly/openWorld annotations: discloses that up to 12 linked stylesheets are fetched, that var()/light-dark()/prefers-color-scheme/[data-theme]/.dark variants are resolved, that opacity is applied, and that uncomputable cases (images, gradients) are reported separately. It also enumerates the failure/thin-margin/assumed-background output buckets.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loads the core purpose and the key differentiator in the first sentence, then layers inputs, resolution behavior, and outputs. It is a dense single paragraph, but nearly every clause carries information; slightly tighter grouping of the input options would help scanning.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

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-shape burden and does: WCAG ratio, APCA Lc, threshold by text size, file/line per failing pair, thin margins, assumed backgrounds, and uncomputable pairs. Combined with the fetch and scheme behavior, an agent has everything needed to call and interpret it.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

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 real meaning: what `url` actually fetches (page, style blocks, up to 12 linked stylesheets), that `html` contributes its style blocks, and that `viewport` drives min-width/max-width media queries with a stated default. It does not elaborate the `scheme` semantics beyond the enum values.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Extracts real foreground and background color pairs from CSS') and immediately differentiates itself from token-based siblings by contrasting with 'guessing roles from token names'. An agent can distinguish this from check_contrast or check_contrast_tokens without opening a schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives clear invocation context: either pass a public `url` or paste `css` (optionally with `html`), and explicitly delineates scope limits ('Reads CSS only: no rendering, inline style attributes, script, or text over photographs'). It doesn't explicitly name a sibling alternative to route to for rendered/image contrast checks, so it falls short of a 5.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources