site-kit

Overview Schema Source Related Servers Discussions Admin

Derive a palette from a subject, when there is no photograph yet

palette_from_subject

Read-onlyIdempotent

Generates a two-state color palette from a subject or hue in OKLCH, emitting hex values and a WCAG contrast matrix to prevent unreadable color pairs.

Instructions

Builds a complete two-state palette from one anchor hue, in OKLCH, and emits hex.

It cannot return one of the ten banned Tailwind indigos or the emerald that replaced them, cannot return pure black or pure white, holds every neutral at 0.005-0.015 chroma of the anchor hue so the greys belong to the same page as the accent, never shifts the hue between light and dark, and returns a WCAG contrast matrix for every pair a page actually puts together — so an unreadable pair cannot be chosen by accident.

It also tells you where the hue came from. If the subject names something real, it names the object. If it does not, it says the hue came from a hash of the words — which is not the same thing, and palette_from_image on a photograph is the stronger move.

Input Schema

TableJSON Schema

Name	Required	Description
`hue`	No	Force an anchor hue in OKLCH degrees, 0-360, if you already know the colour you want.
`subject`	Yes	What the site is about, in a few words. For example: "chess lessons, Brooklyn".
`accent_chroma`	No	How loud the accent is. The corpus band is 0.12-0.22; the default is 0.16.

Output Schema

TableJSON Schema

Name	Required	Description
`css`	No
`fix`	No
`why`	No
`dark`	No
`tool`	Yes	Which tool produced this.
`audit`	No
`light`	No
`notes`	No
`status`	Yes	pass = checked and clean. fail = checked and found problems. skipped = nothing was measured. error = the tool could not run.
`problem`	No
`subject`	No
`contrast`	No
`headline`	Yes	One sentence verdict, safe to show a non-technical user.
`accent_hue`	No
`anchor_hue`	No
`error_code`	No	Set only when status is "error".
`hue_source`	No
`derived_from_something_real`	No

Schema Changelog

Changes observed during successful MCP inspections.

First observedv2.0.0Sep 17, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Annotations already declare readOnlyHint=true, openWorldHint=false, and idempotentHint=true, so the safety and determinism are covered. The description adds extensive behavioral context beyond that: the specific color exclusions (banned indigos, no pure black/white), the neutral chroma band (0.005-0.015), hue stability between light/dark, the WCAG contrast matrix guarantee, and the provenance reporting (object vs hash). These are valuable behavioral traits not derivable from annotations or schema.

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?

The description is moderately long but front-loaded with the core action and constraints. Each paragraph adds a distinct piece of information: the build process and color guarantees, the contrast matrix, and the provenance/alternative tool. It could be slightly tighter but avoids redundancy and every sentence serves a purpose.

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?

Given the tool's complexity, the output schema (present but not shown) and annotations cover safety and determinism. The description covers everything an agent needs to decide when to use it and what to expect: the output (hex, contrast matrix, provenance), the constraints on colors and hue, and the explicit alternative. No critical information is missing.

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

Parameters3/5

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 mentions 'anchor hue' and 'accent_chroma' but does not add meaning beyond what the schema already provides (e.g., the accent_chroma corpus band of 0.12-0.22 and default 0.16 are already in the schema description). No new parameter semantics are introduced.

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?

The description states a specific verb ('builds a complete two-state palette') and resource ('from one anchor hue, in OKLCH, and emits hex'), and explicitly differentiates itself from the sibling palette_from_image by noting that the image-based tool is 'the stronger move' when a photograph exists. It also details what it cannot return, leaving no ambiguity about its function.

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

Usage Guidelines5/5

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

The title and description both specify the condition for use ('when there is no photograph yet'), and the description explicitly names the alternative (palette_from_image) and advises using it when a photograph exists. It also explains the provenance behavior (object vs hash) and why image-based is better, giving clear when-to and when-not-to guidance.

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

Deploy Server