Colour Memory

Multi-Room House Colour Scheme — Provenance-Grouped Where Documented

house_specify

Read-only

Generate a complete multi-room house colour scheme from a single archive. Where the retrieved evidence supports it, rooms are grouped by documented provenance (same object, same pattern colourway, same source citation, same designer, same period+institution); where it does not, they are grouped by perceptual similarity and the response says so -- grouping_basis reports which, and provenance_credit reports how many delivered colours are individually evidenced versus documented as a GROUP (often zero). Every colour is a real archive record either way. Each room gets a full colour card set (dominant/secondary/joinery/textile/accent roles) with paint matches, LRV, illuminant behaviour, and WCAG data. A documentary grouping states exactly which documented fact ties its colours together (e.g. 'documented on the same Fitzwilliam Museum record for the Artichoke hanging, accession T.1-1979') and its weighted grouping_strength score -- historical claims are templated only from fields the archive record actually states; room/surface assignment is disclosed as editorial, never as historical fact. Orientation (north/south/east/west) is recorded as room context and surfaced in each room's light_context; in the current model it does not alter palette selection. Example: concept='Arts and Crafts movement family house', archive='ArtsAndCrafts', rooms=[{label:'Entrance Hall', room_type:'hallway', orientation:'north'}, {label:'Living Room', room_type:'living', orientation:'south'}]. Use interior_specify instead for a single room without cross-room grouping. The response includes house_ref -- pass that (not the full response) to palette_pdf's house_ref input to render the flagship document; the full response is often 60-100KB+, too large to safely resend as another tool call's input. 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

Name	Required	Description	Default
`avoid`	No	Terms to exclude from retrieval.
`rooms`	Yes	One entry per room, e.g. [{label:'Entrance Hall', room_type:'hallway', orientation:'north'}]
`archive`	Yes	Single archive to draw every room's colours from, e.g. 'ArtsAndCrafts'. Required -- invalid names return a clear error listing valid archives.
`concept`	Yes	House-level concept or brief, e.g. 'Arts and Crafts movement family house'
`output_format`	No	'scene_brief' adds a Historical Scene Colour Brief for film and image work: per colour its place, date, observer, timing, source and do-not-claim lines, then DOCUMENTED VISUAL CONSTRAINTS, NEGATIVE / DO-NOT-INVENT constraints and a CREATIVE RECONSTRUCTION BOUNDARY. Evidence only; nothing is invented.	standard
`guidance_level`	No	Who the guidance notes are written for. 'client' (default) for a homeowner; 'decorator' for a trade reader. The specification decisions are identical either way -- only the wording differs.	client
`narrative_mode`	No	Default 'evidence_only'.	evidence_only
`colours_per_room`	No	Default 5.
`shared_house_colours`	No	Default 2.
`minimum_claim_strength`	No	Evidence-grade floor, default 'B'. Explicitly supplied: a hard admission filter, never relaxed -- too few qualifying records fails closed with a per-grade availability map (ARCHIVE_EVIDENCE_POOL_DEPLETED). Left at the implicit default: if the archive's best relevant records sit below it, the design-admissibility floor is relaxed to the archive's best achievable grade and disclosed in the response's evidence_floor block. Colours always keep their true evidence grade either way -- claims are never upgraded.	B
`strict_semantic_colour`	No	Default true -- excludes entries whose quoted colour language contradicts their stored hex.

Output Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedSep 28, 2026

addedInput schema / properties / output_format

Added value: +{
+  "default": "standard",
+  "description": "'scene_brief' adds a Historical Scene Colour Brief for film and image work: per colour its place, date, observer, timing, source and do-not-claim lines, then DOCUMENTED VISUAL CONSTRAINTS, NEGATIVE / DO-NOT-INVENT constraints and a CREATIVE RECONSTRUCTION BOUNDARY. Evidence only; nothing is invented.",
+  "enum": [
+    "standard",
+    "scene_brief"
+  ],
+  "type": "string"
+}

Changed1 schema field changedSep 13, 2026

addedInput schema / properties / guidance_level

Added value: +{
+  "default": "client",
+  "description": "Who the guidance notes are written for. 'client' (default) for a homeowner; 'decorator' for a trade reader. The specification decisions are identical either way -- only the wording differs.",
+  "enum": [
+    "client",
+    "decorator"
+  ],
+  "type": "string"
+}

Changed1 schema field changedAug 29, 2026

changedInput schema / properties / minimum_claim_strength / description

Previous value: -"Evidence-grade floor, default 'B'."New value: +"Evidence-grade floor, default 'B'. Explicitly supplied: a hard admission filter, never relaxed -- too few qualifying records fails closed with a per-grade availability map (ARCHIVE_EVIDENCE_POOL_DEPLETED). Left at the implicit default: if the archive's best relevant records sit below it, the design-admissibility floor is relaxed to the archive's best achievable grade and disclosed in the response's evidence_floor block. Colours always keep their true evidence grade either way -- claims are never upgraded."

Changed1 schema field changedAug 13, 2026

changedInput schema / properties / rooms / items / properties / orientation / description

Previous value: -"Constrains candidate selection for this room, not just narration."New value: +"Optional room orientation. Recorded as descriptive light context and surfaced in light_context; it does not alter candidate selection."

AddedAug 3, 2026

TDQS

A4.7/5.0

Behavior5/5

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

Annotations only declare readOnlyHint=true, so the description carries the real behavioural burden and does so richly: grouping_basis/provenance_credit semantics, fail-closed behaviour with a per-grade availability map, evidence-floor relaxation when the default is left implicit, response size (60-100KB+) that breaks naive chaining, and the rule that historical claims are templated only from stated fields. It also discloses that orientation is recorded but does not alter palette selection.

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

Conciseness3/5

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

The purpose and the sibling routing are front-loaded, which is good, but the body is a dense, multi-clause paragraph that interleaves provenance mechanics, output contents, chaining rules, and ethical caveats. Most sentences earn their place, yet the packing makes key operational rules (house_ref handoff, palette_finalize) harder to locate than a short bulleted structure would.

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 high-complexity, 11-parameter tool with an output schema, the description covers what the schema and annotations cannot: the evidence/provenance model, the fail-closed error path, downstream tool chaining via house_ref, and what the customer should be shown. Nothing an agent needs to invoke it correctly or use its result is missing.

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

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% so the baseline is 3, but the description adds genuine semantics beyond the schema: minimum_claim_strength is described as a hard admission filter when explicitly supplied versus a relaxable default, output_format's scene_brief contents are explained, and orientation's non-effect on selection is stated. It does not, however, add meaning for colours_per_room, shared_house_colours, or narrative_mode beyond their defaults.

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?

Opens with a specific verb+resource ('Generate a complete multi-room house colour scheme from a single archive') and immediately scopes the cross-room grouping behaviour. It explicitly names the sibling it is not ('Use interior_specify instead for a single room without cross-room grouping'), so an agent can route between them without opening either schema.

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?

Names the alternative tool and the condition that selects it (interior_specify for single-room, no grouping), gives the downstream handoff chain (pass house_ref to palette_pdf, not the full response), and specifies the follow-up call (palette_finalize once with final colours). It also states a usage caveat about not presenting archive anchors as recommendations.

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

All Colour Memory tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?