Skip to main content
Glama

Colour Memory

by io.github.DigbyO
OverviewDiscussionsAdmin

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
NameRequiredDescriptionDefault
avoidNoColours, pigments or topics to exclude e.g. ['arsenic green']. Applied before selection.
styleNoStyle direction e.g. 'heritage', 'contemporary', 'maximalist', 'minimal', 'scandi', 'industrial', 'coastal'heritage
archiveNoOptional: 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).
conceptYesRoom concept or brief e.g. 'bold maximalist living room' or 'calm Scandi bedroom'
n_coloursNoNumber of colours in scheme (default 5, max 7)
role_planNoOptional: the room's spatial hierarchy, decided BEFORE colours are retrieved, so retrieval can be asked for candidates that suit a named job on a named surface. The role vocabulary is open -- field, architectural, ground, joinery, material, textile, accent and signal are all reasonable, and a room may need three of them or six. Omit to let the endpoint decide the hierarchy itself (unchanged behaviour).
room_typeNoRoom type e.g. 'living', 'bedroom', 'kitchen', 'study', 'bathroom', 'hallway', 'dining'living
orientationNoRoom orientation e.g. 'north', 'south', 'east', 'west' — affects light advice
output_formatNo'scene_brief' adds a Historical Scene Colour Brief for film and image work: per colour its place, date, observer, timing, source and do-not-claim lines, then DOCUMENTED VISUAL CONSTRAINTS, NEGATIVE / DO-NOT-INVENT constraints and a CREATIVE RECONSTRUCTION BOUNDARY. Evidence only; nothing is invented.standard

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / output_format
      Added value: +{
+  "default": "standard",
+  "description": "'scene_brief' adds a Historical Scene Colour Brief for film and image work: per colour its place, date, observer, timing, source and do-not-claim lines, then DOCUMENTED VISUAL CONSTRAINTS, NEGATIVE / DO-NOT-INVENT constraints and a CREATIVE RECONSTRUCTION BOUNDARY. Evidence only; nothing is invented.",
+  "enum": [
+    "standard",
+    "scene_brief"
+  ],
+  "type": "string"
+}
  2. Changed1 schema field changed
    • addedInput schema / properties / role_plan
      Added value: +{
+  "default": [],
+  "description": "Optional: the room's spatial hierarchy, decided BEFORE colours are retrieved, so retrieval can be asked for candidates that suit a named job on a named surface. The role vocabulary is open -- field, architectural, ground, joinery, material, textile, accent and signal are all reasonable, and a room may need three of them or six. Omit to let the endpoint decide the hierarchy itself (unchanged behaviour).",
+  "items": {
+    "properties": {
+      "allow_contrast": {
+        "default": false,
+        "description": "Whether this role may contrast with the scheme rather than harmonise.",
+        "type": "boolean"
+      },
+      "intent": {
+        "default": "",
+        "description": "What this role is for, in words.",
+        "type": "string"
+      },
+      "proportion": {
+        "description": "ONLY when the plan genuinely specifies one. An ungrounded percentage reads as a measured area split that nobody computed.",
+        "type": "string"
+      },
+      "role": {
+        "description": "The job this colour does in the room e.g. 'ground', 'joinery', 'accent'.",
+        "type": "string"
+      },
+      "surfaces": {
+        "default": [],
+        "description": "Where it goes e.g. ['walls'], ['skirting', 'architrave'].",
+        "items": {
+          "type": "string"
+        },
+        "type": "array"
+      },
+      "target_hex": {
+        "default": "",
+        "description": "Approximately the colour the intent means, stated by you. A TARGET, not the answer -- the archive still supplies the real colour. Without it, 'a warm sunny yellow' is answered by text similarity over record names and can return a mauve sweet pea called Wendy's Joy.",
+        "type": "string"
+      }
+    },
+    "required": [
+      "role"
+    ],
+    "type": "object"
+  },
+  "type": "array"
+}
  3. Changed1 schema field changed
    • addedInput schema / properties / archive
      Added value: +{
+  "default": "",
+  "description": "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).",
+  "type": "string"
+}
  4. Changed1 schema field changed
    • addedInput schema / properties / avoid
      Added value: +{
+  "default": [],
+  "description": "Colours, pigments or topics to exclude e.g. ['arsenic green']. Applied before selection.",
+  "items": {
+    "type": "string"
+  },
+  "type": "array"
+}
  5. Changed1 schema field changed
    • changedOutput schema / (root)
      Previous value: -nullNew value: +{
+  "additionalProperties": true,
+  "description": "Structured JSON response. Shape varies by tool; most return an 'ok' boolean plus a 'result' or 'results' field with the tool's data payload.",
+  "type": "object"
+}
  6. Changed1 schema field changed
    • changedOutput schema / (root)
      Previous value: -{
-  "properties": {
-    "error": {
-      "type": "string"
-    },
-    "ok": {
-      "type": "boolean"
-    },
-    "result": {
-      "type": [
-        "object",
-        "array",
-        "string",
-        "null"
-      ]
-    }
-  },
-  "type": "object"
-}New value: +null
  7. Added

TDQS

A4.4/5.0
Behavior4/5

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

Annotations only declare readOnlyHint=true, but the description adds substantial behavioural context beyond that: the archive lock returns a clear error listing valid names rather than silently widening the search, the result already carries rendered palette plus PNG/PDF/ASE/JSON/CSS downloads, and there is an explicit 'never present archive anchors as your recommendation' caveat. It stops short of describing latency, cost, or determinism of results.

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?

Front-loaded with what it produces, then routes to siblings, then the archive caveat, then the palette_finalize follow-up. It is dense and largely earns its sentences, but the closing instructions (archive anchors warning plus palette_finalize) slightly blur the line between description and workflow policy, making it longer than strictly needed.

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 nine-parameter generation tool with an output schema, the description covers trigger, scope, sibling routing, error behaviour, downloadable artifacts, and the follow-up call contract. An agent has everything needed to select and invoke it correctly.

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 every parameter including nested role_plan fields is already documented in the schema, and much of the description (archive error behaviour, concept examples, style) repeats that text. The description adds framing to role_plan and target_hex but does not introduce syntax or constraints absent from the schema, so the baseline 3 applies.

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 verb (generate) and resource (complete interior colour specification) and enumerates the concrete deliverable components: 60/30/10 assignments, provenance, paint matches, illuminant behaviour, WCAG, rationale. It also explicitly differentiates itself from siblings by naming house_specify for multi-room work and pointing to the PDF sibling route.

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 concrete trigger examples ('bold maximalist living room', 'calm Scandi bedroom'), names the alternative (house_specify) with the condition that selects it (multi-room with cross-room provenance), and states the follow-up rule for calling palette_finalize with a self-chosen palette. When-to-use and when-to-use-something-else are both covered.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All Colour Memory toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources