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

Behavior5/5

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

Despite readOnlyHint being true, the description goes well beyond the annotation by disclosing error behavior for invalid archive names, the fact that the result carries PNG/PDF/ASE/JSON/CSS downloads, and the important caveat to never present archive anchors as recommended colours. It also clarifies what happens downstream via palette_finalize.

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 front-loaded with the core purpose and output, then adds routing and safety caveats. The main waste is the marketing-style phrase 'This is the tool that replaces a colour consultation,' which is not operationally useful, but the rest of the content 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?

For a complex tool with seven parameters and an output schema, the description is notably complete: it covers expected output contents, archive failure modes, alternatives, and post-processing steps. Nothing an agent needs to call the tool correctly appears to be 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 description coverage is 100%, so the schema already documents all seven parameters. The description adds illustrative concept examples and restates the archive-lock behaviour, but it does not meaningfully extend parameter semantics beyond what the schema provides.

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 interior colour specification from a concept or brief.' It names concrete inputs and outputs, and later distinguishes itself from house_specify by saying house_specify is for multi-room schemes with cross-room provenance grouping.

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 routes to alternatives: 'Use /interior-specification/pdf for a downloadable branded PDF version' and 'Use house_specify instead for a multi-room scheme.' It also gives a follow-up instruction to call palette_finalize if the agent selects its own colours, making the intended workflow unambiguous.

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?