Skip to main content
Glama

Colour Memory

by app.railway.up.colour-memory-api-production

Vanderpoel Pairing

vanderpoel_pairing
Read-only

Emily Noyes Vanderpoel's documented 'good' dyad/triad hue groupings (Color Problems, 1902, Plate XXXVI 'Good Dyads or Pairs' and Plate XXXVII 'Good Triads'), served from the build artefacts vanderpoel_dyads.json and vanderpoel_triads.json. Snaps an input hex to the nearest of Vanderpoel's eleven real hue-family labels, resolves that hex against the archive, and returns every documented dyad or triad the label belongs to -- each OTHER member carrying its own nearest real archive match (CIEDE2000), with hex_collision disclosed when the match is tied. Unlike hay_contrast, this carries NO proportional ratio -- only Vanderpoel's own categorical 'good' editorial judgement, printed verbatim on the plates. Returns groupings: null for a near-neutral input, where hue is not meaningfully defined, or when the nearest hue-family label is a member of no dyad or triad -- silence is the honest answer, not a forced match. Member names come from a transcriber's digitisation_alt_text (an accessibility description of the plate image), not verified printed captions; every response states this caveat explicitly (member_source_caveat), not just a code comment. The hue positions used to snap an input to a label are a modern matching convention, not a number Vanderpoel printed -- disclosed per response as label_placement_basis.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
hexYesHex colour, e.g. '#CC1A14'.
n_per_memberNoArchive candidates per partner member (1-5). Default 1, which returns a single archive_match object rather than a list.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
reasonNo
coveredNo
groupingsNoDocumented dyads/triads containing the snapped label. Each carries other_member_labels (Vanderpoel's own words), other_members (each with archive_match and hex_collision), judgement, judgement_basis_verbatim, source_plate and its own member_source_caveat. null -- never [] and never a substituted weaker answer -- when nothing is documented.
input_hexNo
input_snapped_toNoVanderpoel hue-family label the input snapped to.
input_archive_matchNoNearest real archive colour to the input itself, or null if nothing is near enough.
member_source_caveatNo
label_placement_basisNoStates that the snap angles are a modern convention, not a number Vanderpoel printed.
degrees_from_nearest_named_hueNo

TDQS

A4.6/5.0
Behavior5/5

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

Beyond the readOnlyHint annotation, the description discloses CIEDE2000 matching, hex_collision tie handling, label_placement_basis as a modern convention, and member_source_caveat from digitised alt text rather than verified captions. These caveats materially shape agent expectations without contradicting the read-only annotation.

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 long but front-loaded with source and function, and each subsequent sentence earns its place by adding a caveat or distinction that affects correct use. It is denser than strictly necessary, so not a 5, but there is no wasted filler.

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 specialised historical scope and the presence of an output schema, the description covers source provenance, matching algorithm, tie handling, null behaviour, and transparency caveats. Nothing an agent needs to invoke or interpret this tool correctly 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 coverage is 100%, so hex and n_per_member are already well documented in the input schema. The description adds useful behavioural context about archive matches and output shape, but it does not substantially extend the semantic meaning of the parameters themselves beyond what the schema provides.

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 function: it serves Vanderpoel's documented 'good' dyad/triad groupings, snaps an input hex to a hue-family label, resolves it against the archive, and returns matching groupings. It also distinguishes itself from hay_contrast by explicitly stating it carries no proportional ratio, making the tool's categorical historical role unmistakable.

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 description explicitly contrasts with hay_contrast, telling the agent this is the tool for Vanderpoel's editorial categorical pairings rather than ratio-based contrast. It also defines when a null return is appropriate — near-neutral hue, undefined hue, or no matching dyad/triad — so an agent will not force or misinterpret results.

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

All Colour Memory toolsInspect
Try in Browser
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A3.7/5.0
Disambiguation2/5

Multiple tool clusters have unclear boundaries: colour_passport, colour_dna, colour_metrics, and colour_cultural_risk overlap heavily; palette_extract, extract_image_colours, image_palette, and ingest_image cover similar image-colour extraction territory; and compound tools like design_session, image_brief, session_brief, and archive_report_brief duplicate chains of component tools. The descriptions are detailed and occasionally state 'use this instead of X', but an agent still faces many near-duplicate choices.

Naming Consistency3/5

Names are consistently snake_case and often use domain prefixes (colour_, palette_, archive_, brand_, accessibility_), but verb placement is mixed: some are verb_noun (extract_image_colours, query_hex, style_match), others are noun_verb (colour_dna, palette_generate, brand_audit), and a few standalone names (ui_states, tool_guide, meta_capabilities) don't fit either pattern. The convention is readable but not uniform.

Tool Count1/5

At 88 tools, this is far beyond the reasonable well-scoped range and exceeds the 50+ extreme mismatch threshold. Many tools are compound wrappers that consolidate chains of simpler tools, adding redundancy and cognitive load rather than genuine coverage.

Completeness5/5

For the apparent domain, the tool surface is extremely comprehensive: colour extraction, analysis, naming, accessibility, cultural/provenance research, palette generation, brand systems, interior design, ecommerce copy, image briefs, project lifecycle, exports, and diagnostic tools are all present. Persistent objects have list/get/versions/delete/export support, so there are no obvious dead ends.

Resources