Skip to main content
Glama

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 Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. 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"
      +}
  2. 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"
      +}
  3. 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"
      +}
  4. 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"
      +}
  5. 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
  6. Added

TDQS

A4.8/5.0
Behavior5/5

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

Only annotation is readOnlyHint=true, so the description carries most of the burden and does so well: it discloses the archive-restriction error path ('clear error listing valid archive names rather than a silent unrestricted search'), warns against misrepresenting archive anchors as recommendations, and clarifies target-vs-answer semantics and what surface the result is presented on.

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 purpose and input/output contract are front-loaded, and the routing/warning sentences each carry weight. It is dense and long with a few rhetorical lines ('This is the tool that replaces a colour consultation') that could be trimmed, but nothing is misleading.

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?

Eight parameters with a nested-ish role_plan, plus an output schema that already covers return values. Despite that richness the description is complete: it describes what comes back, the error behaviour, and the correct downstream workflow. An agent can call and chain it correctly without opening the schema.

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 goes beyond by explaining the archive locking behaviour and its failure mode, and framing role_plan as a spatial hierarchy decided before retrieval. It adds meaningful framing but largely complements rather than extends the already-complete 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?

States a specific verb+resource (generate an interior colour specification) and enumerates the concrete deliverables: 60/30/10 surface assignments, provenance, paint matches, illuminant behaviour, WCAG. It explicitly demarcates itself from siblings by naming house_specify for multi-room work and the PDF endpoint for downloads.

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?

Names when to use it (room-level briefs, examples given), the alternative (house_specify for multi-room cross-room provenance), the follow-on tool (palette_finalize once you choose your own colours), and the download path. Routing is explicit rather than inferred.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources