Skip to main content
Glama

Extract Dominant Palette Colours

palette_extract
Read-only

Extract dominant colours from an image using k-means++ clustering. Accepts a public image URL or base64-encoded image. Returns hex values with proportional weights sorted by luminance. Optionally runs palette_analyse on the results. Returns hex values with proportions, the input palette_analyse and palette_swatch take. The result already carries the rendered palette and its PNG, PDF, ASE, JSON and CSS downloads, ready to show the customer. The archive anchors a colour was derived from are evidence, not the recommended colours. A final palette chosen from this evidence is registered with palette_finalize, called once with those exact colours, so the customer can see and download what was actually recommended.

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": "palette_extract"
  }
}

Input Schema

NameRequiredDescriptionDefault
kNoNumber of colours to extract (3-12, default 6)
analyseNoIf true, also run palette_analyse on the extracted colours and return archive names
archiveNoExplicit single archive name to restrict matching to e.g. 'MarsColour', 'Japan', 'Victorian'.
image_idNoEphemeral image_id from ingest_image (preferred for images over 50 KB)
image_urlNoPublic URL of the image to extract colours from
image_base64NoBase64-encoded image data (small images only, under 50 KB)
grey_card_hexNoHex value sampled from a grey or white card in the image for white balance correction e.g. #C8C8C8
style_contextNoPlain English style description that restricts archive matching to a coherent set e.g. 'English cottage garden', 'Victorian', 'Japanese', 'MarsColour', 'Arts and Crafts'. Prevents palette colours from being named across unrelated archives.

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • changedInput schema / properties / image_base64 / description
      Previous value: -"Base64-encoded image data"New value: +"Base64-encoded image data (small images only, under 50 KB)"
    • addedInput schema / properties / image_id
      Added value: +{
      +  "description": "Ephemeral image_id from ingest_image (preferred for images over 50 KB)",
      +  "type": "string"
      +}
  2. Changed2 schema fields changed
    • addedInput schema / properties / archive
      Added value: +{
      +  "description": "Explicit single archive name to restrict matching to e.g. 'MarsColour', 'Japan', 'Victorian'.",
      +  "type": "string"
      +}
    • addedInput schema / properties / style_context
      Added value: +{
      +  "description": "Plain English style description that restricts archive matching to a coherent set e.g. 'English cottage garden', 'Victorian', 'Japanese', 'MarsColour', 'Arts and Crafts'. Prevents palette colours from being named across unrelated archives.",
      +  "type": "string"
      +}
  3. Changed1 schema field changed
    • addedInput schema / required
      Added value: +[]
  4. Added

TDQS

B3.4/5.0
Behavior4/5

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

With only readOnlyHint supplied, the description adds real behaviour: output is hex plus proportional weights sorted by luminance, the result embeds a rendered palette and PNG/PDF/ASE/JSON/CSS downloads, and archive anchors are framed as evidence rather than recommendations. That is meaningful context beyond the annotation, though the repetition and the oddly worded lifecycle explanation blur some of it.

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

Conciseness2/5

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

The description repeats itself almost verbatim — 'Returns hex values with proportional weights sorted by luminance' followed shortly by 'Returns hex values with proportions' — and the sentence about palette_analyse/palette_swatch inputs is garbled. The core purpose is not front-loaded cleanly because download-output and lifecycle details are interleaved with it.

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

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For an 8-parameter, zero-required tool with an output schema, the description covers the pipeline and evidence semantics but omits default behaviour when no image source is given and never explains the interaction between image_id, image_url and image_base64. The return-format sentences duplicate what the output schema already supplies.

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 prose adds only marginal meaning. It restates the URL-or-base64 input choice and the analyse flag, but says nothing about k (3-12), grey_card_hex white balance, style_context, or how the sources interact when several are supplied.

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

Purpose4/5

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

States a specific verb and resource ('Extract dominant colours from an image') plus the method ('k-means++ clustering'), which is concrete and actionable. It does not, however, distinguish itself from near-identical siblings such as extract_image_colours or image_palette, so an agent cannot tell them apart from the description alone.

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

Usage Guidelines3/5

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

Usage is only implied through pipeline narrative: run palette_analyse via the analyse flag, then register results with palette_finalize. There is no explicit statement of when to pick this tool over the sibling extraction tools, nor any exclusion or prerequisite beyond the 50 KB hint that already lives in the schema.

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