Colour Memory

Interior Colour Specification — Full Room Brief

interior_specify

Read-only

Generate a complete interior colour specification from a concept or brief. Input a room concept, type, and style — receive a professionally structured colour scheme with 60/30/10 surface assignments, archive colour names with full cultural provenance, Farrow and Ball and Little Greene paint matches, three-illuminant light behaviour (D65 daylight, F11 atrium, Illuminant A incandescent), WCAG accessibility for digital use, and a written cultural rationale explaining why each colour belongs in this room. Examples: 'bold maximalist living room', 'calm Scandi bedroom', 'Victorian study', 'coastal kitchen', 'gallery hallway'. Pass archive to lock the whole scheme to one named archive (e.g. 'ArtsAndCrafts', 'GeorgianPleasures') -- every returned colour will belong to it, or you get a clear error listing valid archive names rather than a silent unrestricted search. Use /interior-specification/pdf for a downloadable branded PDF version. Use house_specify instead for a multi-room scheme with cross-room provenance grouping. This is the tool that replaces a colour consultation. 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	Colours, pigments or topics to exclude e.g. ['arsenic green']. Applied before selection.
`style`	No	Style direction e.g. 'heritage', 'contemporary', 'maximalist', 'minimal', 'scandi', 'industrial', 'coastal'	heritage
`archive`	No	Optional: restrict the candidate pool to this single archive before scoring, e.g. 'ArtsAndCrafts' or 'GeorgianPleasures'. Invalid names return a clear error listing valid archives rather than silently searching everything. Omit for unrestricted cross-archive search (default, unchanged behaviour).
`concept`	Yes	Room concept or brief e.g. 'bold maximalist living room' or 'calm Scandi bedroom'
`n_colours`	No	Number of colours in scheme (default 5, max 7)
`room_type`	No	Room type e.g. 'living', 'bedroom', 'kitchen', 'study', 'bathroom', 'hallway', 'dining'	living
`orientation`	No	Room orientation e.g. 'north', 'south', 'east', 'west' — affects light advice

Output Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

TDQS

A4.5/5.0

Behavior4/5

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

readOnlyHint already covers safety, and the description adds useful behavioral context beyond it: passing archive restricts every returned colour to that archive, invalid names produce a clear error, and the result already carries rendered palette plus PNG/PDF/ASE/JSON/CSS downloads. It also warns against presenting archive anchors as recommended colours.

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 description is front-loaded with the core purpose and examples, but it is long and packed with workflow guidance. Most content earns its place, but phrases like 'This is the tool that replaces a colour consultation' are marketing rather than operational, and the download list partly duplicates what an output schema would convey.

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 complex 7-parameter generator with an output schema, the description covers inputs, examples, archive restriction semantics, downstream alternatives, and final-palette handoff. Nothing an agent needs to call it correctly appears to be missing, and the output schema covers return structure.

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. The description adds value by giving concrete example concepts, clarifying how archive changes search behaviour including the error case, and linking orientation to light advice. This goes beyond the schema's default-value explanations.

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?

States a specific action — 'Generate a complete interior colour specification' — and enumerates distinctive deliverables: 60/30/10 surface assignments, paint matches, three-illuminant light behaviour, WCAG accessibility, and cultural rationale. It also names house_specify as the multi-room alternative, so the agent can distinguish it from sibling palette tools.

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?

Gives explicit routing guidance: use /interior-specification/pdf for a branded PDF and house_specify instead for multi-room schemes. It also gives conditional workflow instructions for archive locking and for calling palette_finalize when the agent selects its own final palette.

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?