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

Behavior5/5

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

Even though readOnlyHint=true is already annotated, the description discloses substantial non-obvious behavior: grouping_basis and provenance_credit semantics, editorial versus historical claims, orientation being recorded but not altering selection, the large response-size hazard, and the warning not to present archive anchors as the recommended colours. This far exceeds annotation coverage and meaningfully informs invocation and downstream tool usage.

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 the tool is complex and nearly every clause carries decision-relevant guidance: grouping logic, evidence disclosure, output size, sibling routing, and finalization workflow. It is front-loaded with the core purpose and organized into distinct behavioral commitments, though some tightening around repeated warnings would improve concision.

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 tool with 9 parameters, an output schema, and multiple downstream integrations, the description covers required inputs, output semantics, cross-tool handoffs, safety caveats about evidence claims, and customer-facing delivery. An agent has everything it needs to invoke this tool correctly and decide what to do with the result.

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 schema already documents every parameter, including orientation's non-influence on selection and minimum_claim_strength's fail-closed behavior. The description adds an example and cross-tool guidance, but it does not need to compensate for missing parameter documentation, so the baseline score of 3 is appropriate.

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 and resource: 'Generate a complete multi-room house colour scheme from a single archive.' It clearly distinguishes itself from interior_specify by explicitly directing single-room use to that sibling tool, so an agent can select this tool with confidence.

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 gives explicit routing guidance: use interior_specify for a single room without cross-room grouping, pass house_ref to palette_pdf to render the flagship document, and call palette_finalize if the agent chooses a final palette of its own. It also tells the agent to show the customer the rendered downloads rather than resending the large response.

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

Disambiguation2/5

Several tool clusters perform near-identical functions: extract_image_colours, image_palette and palette_extract all extract dominant colours from images; colour_passport, colour_dna, colour_metrics and colour_cultural_risk all profile a single hex; and at least six compound 'complete package' tools (agent_brief, archive_report_brief, brand_report, design_session, image_brief, session_brief) overlap heavily in scope. The descriptions try to differentiate -- some even point to tool_guide for routing -- but the volume and similarity of clusters makes misselection likely.

Naming Consistency4/5

The vast majority of tools follow a clear domain_prefix_suffix pattern (colour_, palette_, archive_, brand_, accessibility_, project_) and within families naming is very disciplined (brand_guideline_specify/select/pdf/claims/status, project_get/list/versions/delete). However, a handful of outliers invert the order (extract_image_colours, ingest_image, render_colour_result, query_hex) and some descriptions reference tools that don't exist as endpoints (palette_from_concept, match_paint_system, get_colour_metrics).

Tool Count1/5

88 tools is far beyond any reasonable single-server surface, even for a platform spanning archives, branding, interiors and accessibility. The sheer number forces agents into a massive decision space, and many tools exist purely as convenience wrappers that replace chains of 3-6 other tools, suggesting aggressive consolidation was needed.

Completeness4/5

The surface covers an unusually broad domain -- archive search, colour science, palettes, branding, interiors, accessibility, image extraction, projects, and PDF/Word/Excel exports -- with very few dead ends for end-user workflows. Minor gaps: several compound-tool descriptions reference tools that no longer exist, and valid archive names are only discoverable via error messages rather than a dedicated listing endpoint.

Resources

Need Help?