Turn AI-designed colour palettes into Coolours links, with colour names, CSS and contrast checks
Scored across 3 tools
parse_palette_link is clearly distinct (reading a URL back), but create_palette_link and export_palette overlap since both produce palette output including CSS custom properties. The descriptions do clarify the boundary ('create_palette_link already returns the CSS; use this for the JS object'), which mitigates most confusion.
All names are snake_case with consistent verbs (create, export, parse) and reference 'palette'. The only deviation is export_palette lacking the '_link' suffix that the other two share, a minor inconsistency but still readable and predictable.
Three tools are well-scoped for a narrow domain (palette link round-tripping plus export). It is on the lean side, but each tool earns its place and the domain does not obviously call for more.
The surface covers the core lifecycle: creating a shareable link, exporting a palette, and parsing an edited link back. Coverage is solid for the stated purpose, with only minor gaps (no dedicated validation or listing operation) that agents can work around.
Turn a colour palette you have chosen into a link that opens it in Coolours (coolours.perpetualsummer.ltd), where the user can preview the swatches, tweak them and export them. Use this whenever you propose a colour scheme, so the user can see it rather than read hex codes. Also returns WCAG contrast ratios for every pair of colours: check them before recommending a text/background pairing (4.5 or more for body text, 3 or more for large text and UI components). Returns each colour's Coolours name: use those names when presenting the palette. Also returns the palette as CSS custom properties: whenever you show CSS, use it exactly as given rather than writing your own. Give the user the URL.
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | Palette name shown on the site, e.g. "Fintech Dark" | |
| colours | Yes | Colours in display order. Hex ("#1E293B", "#abc"), rgb() or CSS colour names. No transparency. |
| Name | Required | Description |
|---|---|---|
| css | Yes | CSS custom properties exactly as Coolours exports them. Use as given; variable names match the Coolours UI |
| url | Yes | |
| colours | Yes | Each colour with the name Coolours shows on its swatch |
| contrast | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only declare readOnlyHint=true and openWorldHint=false, and the description adds substantial behavior beyond them: it returns WCAG contrast ratios, Coolours colour names, and CSS custom properties, and it tells the agent to reuse the CSS verbatim and to hand the URL to the user. It does not cover things like rate limits or whether a palette is persisted, but for a read-only link generator the disclosure is 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?
The purpose is front-loaded in the first sentence, and the following sentences each carry actionable guidance (when to use it, how to read the ratios, how to use the CSS and the URL). It is on the long side with a chained "Also returns..." pattern, but almost every clause 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?
With an output schema present, the description need not enumerate return fields, yet it still explains the interpretation of the key values (contrast thresholds of 4.5 and 3) and what to do with the results. An agent has everything needed to call the tool and present the output 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 100%, so both parameters (name, colours) are already documented in the schema with format and length details. The description adds no further meaning about parameter syntax or constraints, matching the baseline 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?
States a specific verb and resource: "Turn a colour palette you have chosen into a link that opens it in Coolours". An agent immediately knows what it produces and where it goes. However, it never names or distinguishes itself from its siblings export_palette and parse_palette_link, so the reader cannot tell from the description alone which of the three to pick.
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 context: "Use this whenever you propose a colour scheme, so the user can see it rather than read hex codes", and prescribes how to act on the output (check contrast before recommending a text/background pairing). It stops short of naming alternatives or exclusion conditions versus the sibling tools, so it is a strong context statement rather than full when/when-not guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Export a palette as CSS custom properties or a JavaScript object, with each colour named after its nearest named colour. Output matches Coolours' own Export feature. create_palette_link already returns the CSS; use this for the JS object, or for a palette you didn't create. Use the output as given: its names match the Coolours UI.
| Name | Required | Description | Default |
|---|---|---|---|
| format | Yes | ||
| colours | Yes | Colours in display order. Hex ("#1E293B", "#abc"), rgb() or CSS colour names. No transparency. |
| Name | Required | Description |
|---|---|---|
| code | Yes |
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 still adds real behavioral context: the output matches Coolours' own Export feature, names match the Coolours UI, and the 'use the output as given' instruction warns against post-processing. It does not cover limits or failure modes (e.g. what happens with unsupported colour input), so not 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?
What the tool does is front-loaded in the first sentence, followed by the sibling routing and a usage caveat. Four short sentences with almost no filler; the final caveat sentence is slightly redundant with the earlier 'matches Coolours' Export feature' claim.
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?
An output schema exists, so return-value details are correctly omitted. Combined with the annotations, the description covers format choice, naming behavior, sibling disambiguation, and a consumption caveat — everything an agent needs 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 coverage is 50%: `colours` is documented in the schema, while `format` is only an enum with no description. The description supplies the meaning of the two format values (CSS custom properties vs JavaScript object), which compensates for part of the gap, but it says nothing about the input colour formats or the 20-item limit beyond what the schema already states.
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 (Export) plus resource (palette) plus the two concrete output forms (CSS custom properties / JavaScript object), and it names the differentiating behavior — each colour named after its nearest named colour. An agent can distinguish it from create_palette_link and parse_palette_link from the text alone.
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?
Explicitly routes the agent: 'create_palette_link already returns the CSS; use this for the JS object, or for a palette you didn't create.' That is a named alternative plus the precise conditions that select this tool over it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read the colours and name back out of a Coolours link (coolours.perpetualsummer.ltd/create/...). Use this when the user pastes a Coolours URL, for example after editing a palette on the site, so you can apply their changes.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | The full Coolours URL |
| Name | Required | Description |
|---|---|---|
| css | Yes | CSS custom properties exactly as Coolours exports them. Use as given; variable names match the Coolours UI |
| name | No | |
| colours | Yes | Each colour with the name Coolours shows on its swatch |
| ignored | Yes | URL segments that are not valid swatches; the site ignores these too |
| contrast | Yes |
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 useful context about what is extracted (colours and name) and the intent (apply the user's changes), but says nothing about malformed/non-Coolours URLs or failure behavior.
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 operation, then the usage condition. No filler; the parenthetical example URL is directly informative.
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?
An output schema exists, so return values need no explanation, and the operation is a simple one-parameter read. Complete enough to invoke correctly, with only minor gaps around invalid-input behavior.
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 'url' parameter is fully documented in the schema. The description only adds an example URL shape, which is mildly helpful but not meaningfully beyond the schema. 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 (read) and resource (colours and name from a Coolours link), with the URL pattern in parentheses. It implicitly contrasts with create_palette_link by describing the inverse direction, but never names the siblings 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?
Gives a clear trigger condition: 'Use this when the user pastes a Coolours URL,' plus a concrete scenario (after editing a palette on the site). No explicit when-not guidance or routing to export_palette/create_palette_link, but the scenario is unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
create_palette_linkexport_paletteparse_palette_linkAI-agent design tools: fonts, font recognition, palettes, color naming, contrast, code, SVG, CSS.
18 color tools: OKLCH, WCAG and APCA contrast fixes, palettes, gradients, color blindness, tokens.
Tailwind CSS palettes (50-950) from any color, the closest Tailwind color, and Tailwind's defaults
Curated design references for AI — real CSS values, typography specs, and color palettes.
Add one secure layer between your agents and this server.
