rnv-color-mcp

save_palette

Persist a named color palette for later retrieval with get_palette or list_palettes. Each entry in colors accepts what every other tool accepts: a hex (#d2bc93), a CSS name (red), an RNV brand name (brand gold), or a saved-palette reference ('Spring line:2'); each is resolved and stored as normalized hex, and an unknown token refuses the whole save naming its position. Optional notes are stored as the palette's description. Author is recorded as RNVizion. The name is refused, with the reason, if it is an RNV brand name, a CSS color name, a 'css:' form, a hex literal, or contains ':' -- a palette resolves ahead of brand and CSS names, so such a name would redefine a color for every caller. This WRITES to the palette store and is the only tool here that does. Reusing an existing name overwrites that palette: save and update are the same call (an upsert), there is no separate update operation. Returns a durable flag: true if the palette reached durable storage (the HF Dataset) and will survive a restart, false if it saved to the local working copy only (which is lost on rebuild), with durable_reason naming the step that stopped it. Use when the user wants to keep a set of colors under a name for reuse across sessions, such as a brand or launch palette; to read a palette back use get_palette, and to see what already exists use list_palettes. The saved name can then be passed to mix_colors, convert_color, and generate_harmony as a palette reference.

Input Schema

TableJSON Schema

Name	Required	Description
`name`	Yes	Unique key the palette is stored under. Reusing an existing name overwrites that palette (upsert). Can be referenced later by other tools as 'name:index', e.g. 'Spring line:2'. Refused, with the reason, if it is an RNV brand name, a CSS color name, a 'css:' form, a hex literal, or contains ':'.
`notes`	No	Optional human-readable description stored as the palette's notes.
`colors`	Yes	Ordered list of colors. Each accepts what every other tool accepts: a hex ('#d2bc93'), a CSS name ('red'), an RNV brand name ('brand gold'), or a saved-palette reference ('Spring line:2'); each is resolved and stored as normalized '#rrggbb'. An unknown token refuses the whole save, naming the position. Order is preserved; at least one required.

Output Schema

TableJSON Schema

Name	Required	Description
`name`	Yes	Name the palette was stored under.
`notes`	Yes	Description stored on the palette; empty if none given.
`colors`	Yes	The hex colors saved, in order, normalized to '#rrggbb'.
`durable`	Yes	True if the palette was written through to the durable HF Dataset and will survive a Space rebuild; False if it saved to the local working copy only (e.g. the Space HF_TOKEN is missing or lacks write scope), meaning it will be lost on the next restart.
`color_count`	Yes	Number of colors in the saved palette.
`overwritten`	Yes	True if a palette with this name already existed and was replaced; False if newly created.
`durable_reason`	Yes	Empty when durable is true. Otherwise names the step that stopped durability: no token, the Dataset could not be reached or hydrated at startup, or the push failed. A false flag with no reason is a shrug; this is the reason.

Schema Changelog

Changes observed during successful MCP inspections.

Changed5 schema fields changedSep 27, 2026

changedInput schema / properties / colors / description

Previous value: -"Ordered list of hex colors, each '#RRGGBB' (e.g. '#d2bc93'). Order is preserved; at least one required."New value: +"Ordered list of colors. Each accepts what every other tool accepts: a hex ('#d2bc93'), a CSS name ('red'), an RNV brand name ('brand gold'), or a saved-palette reference ('Spring line:2'); each is resolved and stored as normalized '#rrggbb'. An unknown token refuses the whole save, naming the position. Order is preserved; at least one required."

changedInput schema / properties / name / description

Previous value: -"Unique key the palette is stored under. Reusing an existing name overwrites that palette (upsert). Can be referenced later by other tools as 'name:index', e.g. 'Spring line:2'."New value: +"Unique key the palette is stored under. Reusing an existing name overwrites that palette (upsert). Can be referenced later by other tools as 'name:index', e.g. 'Spring line:2'. Refused, with the reason, if it is an RNV brand name, a CSS color name, a 'css:' form, a hex literal, or contains ':'."

changedOutput schema / properties / colors / description

Previous value: -"The hex colors saved, in order."New value: +"The hex colors saved, in order, normalized to '#rrggbb'."

addedOutput schema / properties / durable_reason

Added value: +{
+  "description": "Empty when durable is true. Otherwise names the step that stopped durability: no token, the Dataset could not be reached or hydrated at startup, or the push failed. A false flag with no reason is a shrug; this is the reason.",
+  "type": "string"
+}

changedOutput schema / required

Previous value: -[
-  "name",
-  "colors",
-  "notes",
-  "color_count",
-  "overwritten",
-  "durable"
-]New value: +[
+  "name",
+  "colors",
+  "notes",
+  "color_count",
+  "overwritten",
+  "durable",
+  "durable_reason"
+]

Changed2 schema fields changedJul 1, 2026

addedOutput schema / properties / durable

Added value: +{
+  "description": "True if the palette was written through to the durable HF Dataset and will survive a Space rebuild; False if it saved to the local working copy only (e.g. the Space HF_TOKEN is missing or lacks write scope), meaning it will be lost on the next restart.",
+  "type": "boolean"
+}

changedOutput schema / required

Previous value: -[
-  "name",
-  "colors",
-  "notes",
-  "color_count",
-  "overwritten"
-]New value: +[
+  "name",
+  "colors",
+  "notes",
+  "color_count",
+  "overwritten",
+  "durable"
+]

Changed6 schema fields changedJun 26, 2026

addedInput schema / properties / colors / description

Added value: +"Ordered list of hex colors, each '#RRGGBB' (e.g. '#d2bc93'). Order is preserved; at least one required."

addedInput schema / properties / name / description

Added value: +"Unique key the palette is stored under. Reusing an existing name overwrites that palette (upsert). Can be referenced later by other tools as 'name:index', e.g. 'Spring line:2'."

addedInput schema / properties / notes / description

Added value: +"Optional human-readable description stored as the palette's notes."

removedOutput schema / additionalProperties
```
Removed value: -true
```

addedOutput schema / properties

Added value: +{
+  "color_count": {
+    "description": "Number of colors in the saved palette.",
+    "type": "integer"
+  },
+  "colors": {
+    "description": "The hex colors saved, in order.",
+    "items": {
+      "type": "string"
+    },
+    "type": "array"
+  },
+  "name": {
+    "description": "Name the palette was stored under.",
+    "type": "string"
+  },
+  "notes": {
+    "description": "Description stored on the palette; empty if none given.",
+    "type": "string"
+  },
+  "overwritten": {
+    "description": "True if a palette with this name already existed and was replaced; False if newly created.",
+    "type": "boolean"
+  }
+}

addedOutput schema / required

Added value: +[
+  "name",
+  "colors",
+  "notes",
+  "color_count",
+  "overwritten"
+]

First observedJun 25, 2026

TDQS

A4.8/5.0

Behavior5/5

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

With no annotations, the description carries the full burden and does so: it declares this is a write tool and the only one, that save and update are the same upsert, the name-refusal rules and their rationale, the author attribution, and the durable/durable_reason return semantics including the local-copy data-loss caveat.

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 purpose, write status, and upsert semantics, and every sentence carries operational information. It is dense rather than bloated, though a few clauses (name-refusal enumeration, author attribution) could be tightened without loss.

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?

An output schema exists, yet the description still supplies the durable/durable_reason interpretation that the schema alone would not convey, plus the overwrite and refusal behaviors an agent needs before calling. Nothing material is missing for a 3-parameter write tool.

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 already 100%, so the baseline is 3; the description nonetheless adds value by tying the color-token grammar (brand gold, 'Spring line:2') to cross-tool reference semantics and clarifying that notes become the palette's description and that a bad token aborts the whole save naming its position.

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 and resource ('Persist a named color palette') and immediately scopes the sibling set by naming get_palette and list_palettes as the read paths. The agent can distinguish this write tool from the read siblings without opening a schema.

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?

Explicitly says when to use it ('when the user wants to keep a set of colors under a name for reuse across sessions') and routes to alternatives for reading back ('to read a palette back use get_palette... to see what already exists use list_palettes'). It also enumerates downstream consumers (mix_colors, convert_color, generate_harmony).

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

All rnv-color-mcp 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?