Colour Memory

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

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'
`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 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.6/5.0

Behavior5/5

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

Beyond the readOnlyHint, it discloses a great deal: grouping_basis and provenance_credit semantics, the provenance-vs-perceptual fallback, the fail-closed ARCHIVE_EVIDENCE_POOL_DEPLETED behavior, that orientation does not affect selection, and a warning that the response is often 60-100KB+ and too large to resend as another call's input. It also clarifies that historical claims are templated only from fields the record states and surface assignment is editorial.

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?

Purpose and grouping semantics are front-loaded, examples follow, then workflow routing. It is long and dense, and a few clauses (e.g. the light_context/orientation aside) restate schema content, but most sentences carry non-obvious operational guidance that earns its place.

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?

An output schema exists so return values needn't be explained, yet the description still flags key response fields and the documented error mode. Combined with the schema and annotations, nothing an agent needs to call this correctly and chain to palette_pdf/palette_finalize 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 the schema already documents every parameter, including the detailed minimum_claim_strength fail-closed/relax logic and the orientation caveat. The description's orientation note ('it does not alter palette selection') largely restates the schema rather than adding new meaning, so the baseline of 3 applies.

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 opens with a specific verb+resource ('Generate a complete multi-room house colour scheme from a single archive') and enumerates the deliverables (colour cards, paint matches, LRV, light_context, WCAG). It explicitly distinguishes itself from the sibling interior_specify ('single room without cross-room grouping'). An agent can separate it from all other palette/interior tools without opening a 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 exact condition that selects it ('Use interior_specify instead for a single room without cross-room grouping'), and prescribes follow-on routing: pass house_ref (not the response) to palette_pdf, and call palette_finalize once with the agent's own final colours. It also states what not to do ('Never present the archive anchors ... as the colours you are recommending').

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?