Colour Memory

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

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

Behavior5/5

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

Annotations declare readOnlyHint=true, and the description aligns with that by framing the operation as generative/read-only. It adds valuable behavioral context beyond annotations: the archive parameter returns a clear error listing valid archives instead of silently searching, the result carries PNG/PDF/ASE/JSON/CSS downloads, and it warns against presenting archive anchors as recommended colours. No contradiction exists.

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, followed by examples and routing guidance. Every sentence contributes useful information, though a few clauses could be tightened; it is verbose for a reason rather than padded.

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?

Given the tool's complexity, the description is highly complete: it covers inputs, outputs, download formats, error behaviour, alternative tools, and a usage guardrail about archive anchors. An output schema exists, so return-value details need not be repeated, and nothing essential is missing for correct selection and invocation.

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 description coverage is 100%, so the baseline is 3. The description adds meaning beyond the schema by explaining the archive locking behaviour in plain language, giving concrete concept examples, and noting that light behaviour is included in the output—context that helps the agent understand parameter intent without replacing the schema.

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 states a specific verb and resource: 'Generate a complete interior colour specification from a concept or brief.' It clearly differentiates itself from siblings by naming house_specify for multi-room schemes and palette_finalize for finalizing a custom palette, so an agent can distinguish this tool from nearby alternatives.

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 when-to-use guidance: use /interior-specification/pdf for a PDF, use house_specify instead for multi-room schemes, and call palette_finalize if the agent chooses its own palette. It also provides concrete examples like 'bold maximalist living room' and 'calm Scandi bedroom', making invocation conditions clear.

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

Disambiguation2/5

Multiple tool clusters have unclear boundaries: colour_passport, colour_dna, colour_metrics, and colour_cultural_risk overlap heavily; palette_extract, extract_image_colours, image_palette, and ingest_image cover similar image-colour extraction territory; and compound tools like design_session, image_brief, session_brief, and archive_report_brief duplicate chains of component tools. The descriptions are detailed and occasionally state 'use this instead of X', but an agent still faces many near-duplicate choices.

Naming Consistency3/5

Names are consistently snake_case and often use domain prefixes (colour_, palette_, archive_, brand_, accessibility_), but verb placement is mixed: some are verb_noun (extract_image_colours, query_hex, style_match), others are noun_verb (colour_dna, palette_generate, brand_audit), and a few standalone names (ui_states, tool_guide, meta_capabilities) don't fit either pattern. The convention is readable but not uniform.

Tool Count1/5

At 88 tools, this is far beyond the reasonable well-scoped range and exceeds the 50+ extreme mismatch threshold. Many tools are compound wrappers that consolidate chains of simpler tools, adding redundancy and cognitive load rather than genuine coverage.

Completeness5/5

For the apparent domain, the tool surface is extremely comprehensive: colour extraction, analysis, naming, accessibility, cultural/provenance research, palette generation, brand systems, interior design, ecommerce copy, image briefs, project lifecycle, exports, and diagnostic tools are all present. Persistent objects have list/get/versions/delete/export support, so there are no obvious dead ends.

Resources

Need Help?