Colour Memory

Record a Manual Brand Colour Decision

brand_guideline_select

Records which brand_guideline_specify candidate was chosen, which colours should be locked for future iteration, and which claims should be suppressed -- produces a revised brand_ref (same reference, a new version underneath it, exactly like a versioned house_ref). No accounts or reviewer states yet -- this demonstrates decision-making, not a full approval workflow.

Input Schema

TableJSON Schema

Name	Required	Description
`note`	No	Optional free-text rationale, e.g. "Client prefers the quieter system."
`brand_ref`	No	The brand_ref returned by brand_guideline_specify. Supply this OR project_id.
`project_id`	No	The project_id returned by brand_guideline_specify. Use this after a refinement (a continued project has a project_id but no new brand_ref). Supply this OR brand_ref.
`locked_colour_ids`	No	colour_id values to lock for future iteration.
`suppressed_claim_ids`	No	claim_id values to suppress (marked superseded).
`selected_candidate_id`	Yes	Which candidate_id to make canonical.

Output Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Changed3 schema fields changedAug 28, 2026

changedInput schema / properties / brand_ref / description

Previous value: -"The brand_ref returned by brand_guideline_specify."New value: +"The brand_ref returned by brand_guideline_specify. Supply this OR project_id."

addedInput schema / properties / project_id

Added value: +{
+  "description": "The project_id returned by brand_guideline_specify. Use this after a refinement (a continued project has a project_id but no new brand_ref). Supply this OR brand_ref.",
+  "type": "string"
+}

changedInput schema / required

Previous value: -[
-  "brand_ref",
-  "selected_candidate_id"
-]New value: +[
+  "selected_candidate_id"
+]

AddedAug 5, 2026

TDQS

A4.5/5.0

Behavior5/5

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

The description adds meaningful behavioral detail beyond the annotations: it creates a revised brand_ref with the same reference but a new version underneath, like a versioned house_ref. It also scopes behavior by stating there are no accounts or reviewer states yet, which helps set expectations for side effects and workflow position.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single dense sentence that front-loads the core action and includes only useful qualifications. The versioning comparison and the explicit non-inclusion of approval workflow earn their place because they clarify behavior and boundaries without padding.

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 6-parameter tool with full schema coverage and an output schema, the description provides the missing workflow context: where the inputs come from, what the output represents, and what this stage does not include. Nothing critical is missing for an agent to call 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 the schema already documents all six parameters. The description adds high-level framing by naming selected candidate, locked colours, and suppressed claims, but it doesn't add meaning beyond what the property descriptions already convey; the brand_ref/project_id distinction remains explained only in 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 clearly states the tool records a manual brand colour decision: which candidate was chosen, which colours to lock, and which claims to suppress. It ties the action to the sibling brand_guideline_specify tool and distinguishes itself as the decision-recording counterpart, so an agent can tell it apart from brand_guideline_status or brand_guideline_claims.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives clear context: use this after brand_guideline_specify has produced a candidate, and it notes this is decision-making, not a full approval workflow. It does not explicitly enumerate alternates or when-not-to-use conditions, but the connection to specify and the exclusion of approval states provide solid guidance.

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

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

Need Help?