site-kit

Overview Schema Source Related Servers Discussions Admin

Derive a palette from a photograph

palette_from_image

Read-onlyIdempotent

Extract a color palette from an image, with coverage percentages, WCAG contrast matrix, and theme tokens for light/dark modes. Works locally on PNG/JPEG.

Instructions

Quantises an image with median cut or k-means and returns a small, considered palette: the colours the subject is actually made of, with how much of the image each one covers.

Returns a full WCAG 2.1 contrast matrix alongside the colours, computed from relative luminance, so an unreadable pair cannot be chosen by accident. Also returns a ready-made token set for both theme states, which can be passed straight to init_site.

Reads PNG and JPEG (.png, .jpg, .jpeg). Everything is done locally; nothing is uploaded.

Input Schema

TableJSON Schema

Name	Required	Description
`count`	No	How many colours to extract. Default 6.
`image`	Yes	Full path to a PNG or JPEG file.
`algorithm`	No	median-cut (default) splits the colour space at medians, then refines with Lloyd iterations so each colour returned is one the image really contains. k-means seeds with k-means++ instead, and is sometimes better on photographs with soft gradients.
`merge_similar`	No	Drop colours that are nearly identical to one already found. Default true.
`sample_budget`	No	How many pixels to sample. Default 20000, which is plenty and keeps this instant.

Output Schema

TableJSON Schema

Name	Required	Description
`fix`	No
`why`	No
`tool`	Yes	Which tool produced this.
`image`	No
`format`	No
`status`	Yes	pass = checked and clean. fail = checked and found problems. skipped = nothing was measured. error = the tool could not run.
`problem`	No
`headline`	Yes	One sentence verdict, safe to show a non-technical user.
`swatches`	No
`algorithm`	No
`dimensions`	No
`error_code`	No	Set only when status is "error".
`corpus_audit`	No
`pixels_sampled`	No
`readable_pairs`	No
`contrast_matrix`	No
`suggested_tokens`	No
`banned_hexes_checked`	No

Schema Changelog

Changes observed during successful MCP inspections.

First observedv2.0.0Sep 17, 2026

TDQS

A4.5/5.0

Behavior5/5

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

Annotations already declare readOnlyHint and idempotent hints, and the description adds valuable behavioral detail: quantization approach, output contents, WCAG contrast computation, and explicitly that nothing is uploaded. This goes well beyond the annotations and gives an agent confidence about privacy and side-effect-free execution.

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

Conciseness5/5

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

Three tight paragraphs with a clear progression: what it does, what it returns, and practical constraints (formats, privacy). Every sentence adds information, and the most important output characteristics are front-loaded.

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?

For a tool with five parameters and an output schema, the description fully covers formats, algorithm behavior, output artifacts, and integration with init_site. Nothing an agent needs to decide whether to call this tool is missing, and the output schema handles return-value details.

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 schema fully documents count, image, algorithm, merge_similar, and sample_budget. The description adds some connecting context (median cut vs k-means, coverage information) but does not materially enrich parameter meaning beyond what the schema already provides. Baseline 3 is appropriate.

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 names a specific verb (quantises), a clear resource (image), and the exact output (palette with coverage, WCAG contrast matrix, token set). It is unambiguous about what the tool does and is easily distinguishable from siblings like palette_from_subject by the emphasis on photograph-derived palettes.

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?

The description gives clear context for when the tool is appropriate: extracting a palette from a photograph, with supported formats and a local-processing guarantee. It also offers algorithm-selection guidance (k-means for soft gradients) but does not explicitly state when to prefer this over palette_from_subject or other palette-related alternatives.

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

Deploy Server