rnv-color-mcp

save_palette

Persist a named color palette for later retrieval with get_palette or list_palettes. colors is a list of hex values; optional notes are stored as the palette's description. Author is recorded as RNVizion. 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, e.g. when the Space HF_TOKEN is missing or lacks write scope). 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'.
`notes`	No	Optional human-readable description stored as the palette's notes.
`colors`	Yes	Ordered list of hex colors, each '#RRGGBB' (e.g. '#d2bc93'). 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.
`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.

Schema Changelog

Changes observed during successful MCP inspections.

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

Behavior5/5

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

No annotations are provided, so the description carries the full burden. It discloses the write operation, upsert behavior, the fact that it overwrites on name reuse, the author being set to RNVizion, and the durable flag semantics including the failure mode when HF_TOKEN is missing or lacks write scope. This is exceptionally transparent.

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 dense but every sentence adds critical information. It starts with the core action and then efficiently covers related tools, upsert semantics, durability, and when to use. No wasted words despite the depth.

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 (write, upsert, durability, cross-tool integration), the description covers all necessary context: purpose, behavior, edge cases, return value, alternatives, and downstream usage. Even with an output schema present, the description explains the meaningful part of the response (durable flag) which is essential for the agent.

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%, but the description adds meaning beyond the schema: colors are hex values, notes become the palette's description, the name acts as an upsert key, and the author is recorded as RNVizion. It also explains the return durable flag. This enriches the parameter context beyond the baseline.

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 opens with a specific verb and resource: 'Persist a named color palette for later retrieval.' It clearly distinguishes from siblings by naming get_palette and list_palettes as retrieval tools and stating this is 'the only tool here that does' write operations.

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?

Provides explicit usage guidance: 'Use when the user wants to keep a set of colors under a name for reuse across sessions.' It gives alternatives: 'to read a palette back use get_palette, and to see what already exists use list_palettes.' Also explains how the saved name can be passed to other tools.

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?