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'
`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

TDQS

A4.7/5.0

Behavior5/5

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

Even with readOnlyHint=true lowering the bar, the description adds substantial behavioral context: it discloses that the full response can be 60-100KB+, explains how grouping_basis and provenance_credit report evidentiary grouping, and states that room/surface assignment is editorial rather than historical fact. It also gives an important warning not to present archive anchors as recommended colours. There is no contradiction with the readOnly annotation.

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

Conciseness5/5

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

The description is long but dense, and every sentence earns its place given the tool's complexity. The purpose is front-loaded, followed by grouping behavior, output-artifact details, routing to sibling tools, and integrity caveats. There is no filler or repetition of schema content.

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?

The description covers the full usage lifecycle: what the tool generates, how evidence grouping works, how to route to interior_specify, how to pass house_ref to palette_pdf, and how to call palette_finalize if needed. It also communicates output size, download artifacts, and evidence-integrity rules. Given that an output schema exists, this is complete enough for correct invocation and follow-up actions.

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 schema already documents all 9 parameters with meaningful descriptions. The tool description does add a concrete example call and clarifies that orientation is recorded as context but does not alter palette selection, but it does not substantially expand parameter meaning beyond the schema. This is adequate but not exceptional for parameter semantics.

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 and resource: 'Generate a complete multi-room house colour scheme from a single archive.' The description also differentiates the tool from a close sibling by saying 'Use interior_specify instead for a single room without cross-room grouping,' so an agent can select it confidently. The title's provenance-grouping cue is reinforced immediately in the first lines.

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 names the alternative tool and the exact condition for choosing it: 'Use interior_specify instead for a single room without cross-room grouping.' It also provides downstream routing guidance, including passing house_ref to palette_pdf and calling palette_finalize if the agent makes its own final palette choice. This is direct, actionable when-to-use guidance rather than an implied context.

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

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.8/5.0

Disambiguation2/5

With 88 tools, there is substantial overlap: colour_passport vs colour_dna vs colour_metrics vs colour_cultural_risk are explicit components of the same object; palette_concept vs palette_strict vs palette_generate vs palette_heritage overlap heavily; and four image extraction tools exist (extract_image_colours, image_palette, palette_extact, ingest_image). Although descriptions are detailed and tool_guide exists, an agent will frequently struggle to select the correct tool unambiguously.

Naming Consistency5/5

Nearly all tools follow a consistent snake_case noun_verb or domain-prefixed pattern (colour_*, palette_*, brand_*, archive_*, project_*, accessibility_*). The naming is uniform and predictable, with no mixing of styles or verb conventions across the set.

Tool Count1/5

88 tools is an extreme count for an MCP server. Even honoring the broad domain, the rubric places 50+ at the extreme end, and the high overlap between compound and individual tools suggests many could be consolidated or exposed as sub-resources rather than top-level tools.

Completeness5/5

The tool surface covers the full colour lifecycle: lookup, analysis, palettes, brand systems, accessibility, image extraction, interior design, archival research, reports, PDF generation, and project management. Workflows have clear entry points and few dead ends, and the presence of compound tools further closes integration gaps.

Resources

Need Help?