Skip to main content
Glama

Extract and Name Colours from an Image

image_palette
Read-only

Upload an image (base64 encoded) and extract its dominant colour palette, with each colour matched to its nearest named archive entry with full cultural provenance. Uses K-means++ extraction; sRGB pixels are read as D65 CIELAB for matching. Returns up to 5 dominant colours, each with archive name, cultural story, nearest RAL standard, and WCAG accessibility data. Works for product photography, interior photos, artwork, brand assets, and mood boards. The image is never stored — processed in memory only. The result already carries the rendered palette and its PNG, PDF, ASE, JSON and CSS downloads -- show them to the customer. Never present the archive anchors a colour was derived from as the colours you are recommending. If you go on to choose a final palette OF YOUR OWN from this evidence, call palette_finalize once with those exact colours so the customer can see and download what you actually recommended.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
archiveNoOptional: restrict archive matching to a specific archive
n_coloursNoNumber of dominant colours to extract (default 5, max 5)
media_typeNoImage MIME type e.g. 'image/jpeg'image/jpeg
image_base64YesBase64 encoded image (JPEG, PNG, WebP)

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedOutput schema / (root)
      Previous value: -nullNew value: +{
      +  "additionalProperties": true,
      +  "description": "Structured JSON response. Shape varies by tool; most return an 'ok' boolean plus a 'result' or 'results' field with the tool's data payload.",
      +  "type": "object"
      +}
  2. Changed1 schema field changed
    • changedOutput schema / (root)
      Previous value: -{
      -  "properties": {
      -    "error": {
      -      "type": "string"
      -    },
      -    "ok": {
      -      "type": "boolean"
      -    },
      -    "result": {
      -      "type": [
      -        "object",
      -        "array",
      -        "string",
      -        "null"
      -      ]
      -    }
      -  },
      -  "type": "object"
      -}New value: +null
  3. Added

TDQS

A4.1/5.0
Behavior5/5

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

The description richly complements the readOnlyHint annotation by stating the image 'is never stored — processed in memory only,' explaining the K-means++ extraction and D65 CIELAB matching, and disclosing that the result carries downloadable PNG, PDF, ASE, JSON and CSS assets. It also surfaces important behavioural cautions about not presenting archive anchors as recommendations. This goes well beyond the structured annotation without contradicting it.

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 information-dense but every sentence contributes operational value: purpose, algorithm, output contents, supported use cases, privacy, and downstream workflow. It is somewhat long, but the length is justified by the tool's behavioural complexity and the important customer-facing instructions.

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 rich output schema and readOnlyHint annotation, the description is nearly complete on its own. It covers what the tool returns, the matching method, privacy behaviour, supported image domains, and the required handoff to palette_finalize when the agent composes its own palette. No critical calling 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 input schema already documents image_base64, archive, n_colours, and media_type adequately. The tool description adds useful output context but does not materially enrich parameter-level meaning beyond what the schema already provides. Baseline 3 is therefore appropriate.

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?

The description clearly states the tool extracts and names a dominant colour palette from an uploaded image, with a specific matching behaviour ('nearest named archive entry with full cultural provenance'). It does not, however, explicitly distinguish itself from sibling tools such as palette_extract or extract_image_colours, so it relies on the reader to infer the differentiation.

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 usage context by listing applicable inputs: 'product photography, interior photos, artwork, brand assets, and mood boards.' It also gives downstream workflow guidance (call palette_finalize when choosing your own final palette), but it does not explicitly state when not to use this tool or which sibling should be used instead.

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