A
licenseNot graded
qualityD
maintenanceA Model Context Protocol server that provides color conversion between multiple color spaces including RGB, RGBA, HEX, HSL, OKLCH, LAB, and CMYK.
225
2
MIT
rnv-color-mcp
Officialby RNVizion
The rnv-color-mcp server provides a complete color workflow — mixing, converting, harmonizing, comparing, and managing palettes — plus text transformation and accessibility checks.
Mix Colors (
mix_colors): Blend up to 12 colors using multiple models:lab(perceptual, default),rgb,hsv,paint(Kubelka-Munk pigment physics),ryb(artist's color wheel), orcmy(subtractive/printer-ink). Supports optional integer weights to bias the blend.Convert Color (
convert_color): Transform colors betweenhex,rgb,hsv,hsl, andlabformats.Generate Harmony (
generate_harmony): Create color harmonies from a base color — complementary, analogous, triadic, split-complementary, tetradic/square, monochromatic, or compound.Color Difference (
color_difference): Calculate perceptual difference (Delta-E) between two colors using CIEDE2000 (default) or CIE76, with a plain-language interpretation.Contrast Check (
contrast_check): Compute WCAG contrast ratio (1.0–21.0) between foreground and background colors, with AA/AAA pass/fail results for normal text, large text, and UI components.Transform Text (
transform_text): Apply 11 deterministic case transformations: UPPERCASE, lowercase, Title Case, Sentence case, camelCase, PascalCase, snake_case, CONSTANT_CASE, kebab-case, dot.case, and iNVERTED cASE.Palette Management: Save (
save_palette), list (list_palettes), and retrieve (get_palette) named color palettes with optional notes, persisted across restarts.
Universal color input accepts hex values (#d2bc93), CSS names (red), RNV brand names, or saved-palette references. Unknown color names are refused, never guessed.
Provides durable palette storage via Hugging Face Datasets, allowing saved palettes to persist across server restarts when configured with HF_TOKEN.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type
@followed by the MCP server name and your instructions, e.g., "@rnv-color-mcpmix navy blue and teal"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
title: RNV Color MCP emoji: 🎨 colorFrom: gray colorTo: yellow sdk: docker app_port: 7860 pinned: false short_description: Color workflow MCP server
RNV Color MCP
A remote MCP server for a complete color workflow: mix, convert, harmonize, and remember palettes, called in plain language by Claude (or any MCP client), and by anything else that speaks MCP.
Related MCP server: MCP Color Server
Why this exists
The color logic already lived in my desktop suite: a mixer, a palette manager, a picker. Instead of rebuilding it for every new project, I lifted the engine out once and exposed it as a single server. A Claude conversation calls it today; a fashion design app will call the same backend tomorrow. Build the engine once, let both consume it.
Underneath, it's a small thesis about working with LLMs: a model is great at deciding what you want and terrible at exact arithmetic. So the model picks the tool and the intent, and the tool owns the precise values. The server resolves or it refuses; it never guesses a color.
What it does
Tool | What it does |
| Blend up to 12 colors. Modes: |
| Convert between hex, rgb, hsv, hsl, lab. |
| complementary, analogous, triadic, split-complementary, tetradic/square, monochromatic, compound. |
| Perceptual difference (Delta-E, CIEDE2000 or CIE76) between two colors. |
| WCAG contrast ratio plus AA/AAA pass/fail for accessible text. |
| 11 exact case transforms (UPPERCASE, camelCase, snake_case, …). |
| Name a palette, recall it later. Persists across restarts. |
Every color input accepts a hex (#d2bc93), a CSS name (red), an RNV brand name
(brand gold, near-black), or a saved-palette reference (Spring line, or Spring line:2
for its second swatch). Brand names win over CSS names on collision; css:gold forces the
universal one.
Connect in 30 seconds
This is a hosted server, so there's nothing to install. In Claude: Settings → Connectors → Add custom connector, then paste:
https://rnvizion-rnv-color-mcp.hf.space/mcpLeave auth blank, add it, then toggle it on in a chat with the + menu.
Try it
Once connected, just talk:
"Save a palette named Spring line: near-black and brand gold." "Pull my Spring line palette and give me three complementary accents for outerwear." "Mix paint-red and paint-blue like real pigment."
The first call saves; the second composes get_palette → generate_harmony; the third runs the
Kubelka-Munk paint model, so the blend darkens the way mixed pigment actually does, not the way
averaged light does.
Authentication
The server implements OAuth 2.1 resource-server authentication with enforced per-tool scopes; the public endpoint runs with it disabled, so connecting by URL works with no setup.
When enabled (RNV_AUTH=1 plus a key source), the server validates bearer tokens against issuer,
audience, expiry, and signature; serves RFC 9728
protected resource metadata at /.well-known/oauth-protected-resource/mcp; returns a
spec-compliant WWW-Authenticate challenge on 401; and enforces two scopes: read covers the
eight read-only tools, write covers save_palette, the only tool that mutates anything. A token
without the write scope does not see save_palette in its tool list at all; out-of-scope tools
are hidden rather than refused, so nothing leaks about what exists behind a scope you lack.
Enforcement is covered by the test suite, run in CI on every push (status badge at the top of this file), spanning the token-validation matrix (missing, malformed, wrong issuer, wrong audience, expired, valid) and end-to-end scope enforcement over real HTTP. The suite mints its own keys and requires no credentials. The tests cover the auth layer; the color engine itself is not under automated test.
Moving from the self-issued development key to a real identity provider is configuration, not
code: point RNV_AUTH_JWKS_URI at the provider's JWKS endpoint and set the issuer and audience
to match.
Variable | Purpose |
| The switch. |
| A provider's JWKS endpoint. Use this or |
| A static PEM public key, for development against a self-issued keypair. |
| Expected token issuer; also advertised as the authorization server. |
| Expected token audience. Bound to the |
| Server base URL, without |
With RNV_AUTH on and no key source set, the server refuses to start rather than coming up
unprotected.
Run it yourself
pip install -r requirements.txt
python server.py # Streamable HTTP on $PORT (default 7860)
pip install -r tests/requirements-dev.txt
python -m pytest # auth + scope tests
python tests/server_test.py # smoke: exercises all 9 tools in-processSet HF_TOKEN to write palettes through to a private Hugging Face Dataset for durable storage.
Running a copy?
The code is MIT-licensed; you're free to rebuild, host, and modify it, and I'd rather you did than didn't. What a licence can't carry is the environment.
Some capabilities depend on how a deployment is configured, not on the code alone:
Palette persistence needs
HF_TOKENand a writable Dataset. Without it, saves land in process memory and vanish with the container.Scoped authorization needs
RNV_AUTHand a configured issuer. Unset, the server runs open — which is correct for a public demo and wrong for anything else.Anything that fetches needs outbound network access.
A rebuild missing one of those usually doesn't fail loudly; it returns success and drops the result. That is worse than an outage, because an outage tells you.
So: if you're running a copy and something behaves oddly, check the environment before you check the code, and check against the canonical deployment before you file anything.
Canonical endpoint: https://rnvizion-rnv-color-mcp.hf.space/mcp
Canonical source: https://github.com/RNVizion/rnv-color-mcp
A copy served from another URL may be older, modified, or differently configured. That's fine and allowed; it just isn't this.
The tools resolve or refuse; they don't guess. A copy can only keep that promise if the ground under it was checked first.
Notes
Brand colors are mirrored, not owned. The vocabulary lives in
engine/brand_vocab.py, mirrored fromengine/brand.pyin RNVizion/rnv-brand and corrected when drift is detected against it. It is carried locally on purpose:resolve_coloris the hot path, and a fetch there would have to answer what happens when it fails — fail closed and the server refuses every color, fall back and the local copy is needed anyway, guess and the promise above is already broken. Identifiers are local by design; the check compares values, never names. The register and its reasoning live inBRAND_COLORS.md, inrnv-brand.Engine is dependency-free. The color math, harmony, and text logic are pure standard library, lifted Qt-free from the desktop apps. Only the server layer needs
fastmcp.Honest by design. An unknown color name is refused, not guessed. An unverifiable token is refused, with a reason. Same principle at both layers.
Stack
Python · FastMCP (Streamable HTTP) · Hugging Face Spaces
(Docker) · huggingface_hub for durable palette storage.
Built by Christian "RNVizion" Smith.
Available Tools
9 toolscolor_differenceAInspect
Perceptual difference (Delta-E) between two colors. color1 and color2 accept a hex, CSS name, RNV brand name, or saved-palette reference. method is 'ciede2000' (default, modern standard) or 'cie76'. A value near 1.0 is the threshold the eye can just notice; larger means more different. Returns the value and a plain-language interpretation.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| color1 | Yes | ||
| color2 | Yes | ||
| method | No | ciede2000 |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
A4.6/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description fills in behavioral details: accepted color formats (hex, CSS name, RNV brand name, saved-palette reference), method defaults, and a threshold for human perception. It could mention side-effects or limitations but overall is informative.
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 concise and front-loaded: first sentence states purpose, then covers inputs and method, then interpretation, then return value. Every sentence adds value with no redundancy.
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 presence of an output schema, the description covers inputs and behavior completely. It explains what the return value means (value and interpretation) beyond what the schema likely provides. All necessary context is present for the agent to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description adds substantial meaning: color1 and color2 accept multiple formats, the 'method' parameter has clear options and a default. This fully compensates for the lack of schema descriptions.
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 computes 'Perceptual difference (Delta-E) between two colors', specifying the exact verb and resource. It distinguishes from siblings like 'contrast_check' (likely contrast ratio) and 'convert_color' by focusing on perceptual difference.
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 explains the two method options ('ciede2000' vs 'cie76') and their interpretations, but does not explicitly guide when to use this tool over alternatives like 'contrast_check' or 'generate_harmony'. It implies usage through parameter details but lacks explicit context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
contrast_checkAInspect
WCAG contrast ratio between a foreground and background color, for accessibility. Both accept a hex, CSS name, RNV brand name, or saved-palette reference. Returns the ratio (1.0-21.0) plus pass/fail for AA and AAA at normal and large text sizes and for UI components. Use this to check if text will be readable on a background.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| background | Yes | ||
| foreground | Yes |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
A4.6/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Describes output and accepted input formats. No annotations provided, so description carries full burden. Does not explicitly state it is read-only, but behavior is transparent regarding what it returns.
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?
Two sentences, no wasted words. First sentence states purpose and output, second adds input formats and usage hint. Front-loaded with key information.
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 simple parameters, output schema exists (though not shown), and description covers input formats, output details, and usage context. Complete for a straightforward tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% but description adds significant meaning: both parameters accept hex, CSS name, RNV brand name, or saved-palette reference. This compensates fully for missing schema descriptions.
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?
Clearly states the tool checks WCAG contrast ratio between foreground and background colors for accessibility. Specifies output includes ratio and pass/fail for AA/AAA. Distinguishes from sibling tools like color_difference by focusing on accessibility.
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?
Explicitly tells when to use: 'Use this to check if text will be readable on a background.' Does not mention when not to use or alternative tools, but the purpose is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
convert_colorAInspect
Convert a color between formats. Input accepts a hex, CSS name, RNV brand name, or saved-palette reference. With to set to one of hex/rgb/hsv/hsl/lab, returns just that format; otherwise returns all of them.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| to | No | ||
| color | Yes |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
A4.5/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears full burden. It discloses accepted input formats, the optional 'to' parameter, and the conditional output (single format or all). It does not mention error handling or edge cases, but for a conversion tool this is reasonably 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 two sentences, no filler. First sentence states the core action. Second sentence details parameters and output. Perfectly front-loaded and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the low complexity and presence of an output schema, the description covers input types, optional parameter, and output behavior. It lacks mention of error handling, but for a color conversion tool this is likely sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. It does so effectively: it explains that 'color' accepts hex, CSS name, RNV brand name, or saved-palette reference, and that 'to' can be one of hex/rgb/hsv/hsl/lab or null to return all formats. This adds essential meaning beyond the plain 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's purpose: 'Convert a color between formats.' It specifies the input types (hex, CSS name, RNV brand name, saved-palette reference) and the output behavior depending on the 'to' parameter. This clearly distinguishes it from sibling tools like color_difference or contrast_check.
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 states when to use the tool (when converting colors) and explains the optional 'to' parameter for output format. However, it does not explicitly mention when not to use it or provide alternatives among siblings, though the context makes it clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
generate_harmonyAInspect
Generate a color harmony from a base color. base accepts a hex, CSS name, RNV brand name, or saved-palette reference (e.g. 'Spring line:2'). scheme is one of: complementary, analogous, triadic, split-complementary, tetradic (a.k.a. square), monochromatic, compound. Returns a list of hex colors.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| base | Yes | ||
| scheme | Yes |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
A3.8/5.0
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must bear full responsibility for behavioral disclosure. It mentions that the tool returns a list of hex colors but does not address side effects, idempotency, authentication needs, or any limitations such as rate limits or destructive actions.
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 concise at two sentences, with the first sentence clearly stating the tool's purpose and the second detailing parameter specifications. Every sentence adds value, and there is no superfluous content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (two required parameters, no enums in schema but description provides enums), the description covers input formats and output type adequately. It omits error handling or edge cases, but for a generation tool this is acceptable. The output schema exists, so return values are implied.
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?
The input schema has 0% description coverage, leaving the description to explain parameter semantics. It effectively clarifies that 'base' accepts hex, CSS name, brand name, or saved-palette reference, and enumerates the valid 'scheme' options. However, it could provide examples for the saved-palette reference format.
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 generates a color harmony from a base color, specifying that it accepts various color formats and lists the available scheme types. This specific verb+resource combination distinguishes it from sibling tools like convert_color or contrast_check.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use for generating harmony schemes but does not explicitly state when to use this tool versus alternatives like get_palette or list_palettes. No exclusion criteria or alternative suggestions are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_paletteAInspect
Retrieve one saved palette by name, returning its colors and metadata. Returns null if no palette by that name exists.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
A4.3/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses return of colors and metadata, and null if not found. No annotations exist, so description bears full burden; missing details like auth or side effects, but adequate for a simple read tool.
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?
Two sentences, front-loaded with purpose and output, no redundant information.
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?
Covers retrieval, return content, and null case; output schema provides return structure; complete for a straightforward getter.
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 has 0% description coverage but single string param 'name'; description says 'by name' linking to palette name, which is minimal but sufficient for a simple key.
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?
Description clearly states verb 'Retrieve' and resource 'palette by name', distinguishes from siblings like list_palettes (list all) and save_palette (create/update).
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?
Implies usage for fetching specific palette by name; no explicit when-not-to-use or alternatives, but context from sibling names provides differentiation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_palettesAInspect
List every saved palette as name + colors.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
A4.3/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but the description clearly indicates a read-only listing operation. Could explicitly state no side effects, but 'list' sufficiently implies non-destructive behavior.
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?
Extremely concise, single sentence with essential information. Front-loaded verb and resource, no wasted words.
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 parameterless list tool with an output schema, the description fully covers what the tool does and returns. No gaps.
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?
No parameters exist; schema coverage is 100%. Baseline score of 4 for zero-parameter tools as description adds no param info.
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?
Description uses specific verb 'list' and resource 'every saved palette', with output format 'name + colors'. Clearly distinguishes from siblings like get_palette (single palette) and save_palette.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when or when not to use. Implies it's for viewing all palettes, but doesn't mention alternatives or contexts like filtering.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
mix_colorsAInspect
Blend up to 12 colors into one. Each color may be a hex (#d2bc93), a CSS name (red), an RNV brand name (brand gold, near-black), or a saved-palette reference (Spring line, or 'Spring line:2' for its 2nd swatch). Optional integer weights bias the blend (defaults to equal). mode selects the model: rgb/hsv/lab are digital blends (lab is perceptual and the default); paint mixes pigments via Kubelka-Munk physics (colors darken like real paint); ryb is the artist's color wheel; cmy is subtractive like printer inks. Returns hex and rgb.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| mode | No | lab | |
| colors | Yes | ||
| weights | No |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
A4/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Describes return values (hex, rgb), optional weights, mode options with explanations (digital vs paint), though lacks disclosure on side effects or performance implications.
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?
Dense but informative single paragraph; could be structured with bullet points for readability, but all sentences add value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers inputs, modes, and return types; minor gaps on weight-colors alignment and output schema structure, but largely complete given complexity and output schema existence.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema coverage, description fully explains all parameters: colors format, weights, mode choices and defaults, adding significant meaning beyond 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?
Clearly states the tool blends colors, specifies input types and modes, and is distinct from sibling tools like color_difference or convert_color.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs siblings or alternatives; does not mention prerequisites or exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
save_paletteAInspect
Save (or update) a named palette for later reuse, e.g. a launch line. colors is a list of hex values; optional notes are stored as the palette's description. Author is recorded as RNVizion.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | ||
| notes | No | ||
| colors | Yes |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
A4.2/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description adds value by specifying that colors are hex values, notes become the palette's description, and author is recorded as 'RNVizion'. It misses potential destructive behavior or permission needs but covers key aspects.
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?
Two sentences, no fluff, front-loaded with purpose. Every part earns its place, and the structure is clear.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity and presence of an output schema, the description covers the main aspects: create/update behavior, parameter hints, and side effect of recording author. Missing details like constraints on hex values or idempotency, but sufficient for most use cases.
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 0%, but the description explains 'colors' and 'notes' thoroughly, including format and storage behavior. The 'name' parameter is not explained beyond its requirement. Overall, it compensates well for the missing schema descriptions.
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 saves or updates a named palette for reuse, with an example. It distinguishes from siblings like get_palette and list_palettes by focusing on creation/update.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for saving/updating palettes but gives no explicit guidance on when to use save vs update, nor any conditions or alternatives. It lacks explicit context for compared to siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
transform_textAInspect
Apply an exact, deterministic text transformation. operation is one of: UPPERCASE, lowercase, 'Title Case', 'Sentence case', camelCase, PascalCase, snake_case, CONSTANT_CASE, kebab-case, dot.case, 'iNVERTED cASE'. Use this rather than converting case by hand.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | ||
| operation | Yes |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
A4/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must cover behavioral traits. It states 'exact, deterministic,' which implies predictable output, but it does not disclose error handling for invalid operations, side effects, performance characteristics, or the output format. The output schema exists but is not described, leaving some behavioral aspects unclear.
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 concise (two sentences) and front-loaded with the core purpose. Every sentence adds value: the first defines the tool, the second lists operations and provides usage guidance. No extraneous information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple transformation tool with two string parameters and an existing output schema (not shown), the description covers the main intent and options. It lacks parameter descriptions for 'text' and could mention return format or error behavior, but the output schema likely fills that gap. Overall, it is nearly complete.
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 0%, so the description must add meaning. It lists the allowed operations for the 'operation' parameter but does not describe the 'text' parameter beyond being the input string. While the operations are enumerated, no details on their effects or constraints are provided. Partial compensation but not complete.
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 applies an 'exact, deterministic text transformation' and enumerates the supported operations (UPPERCASE, lowercase, etc.). It distinguishes itself from manual case conversion, and the sibling tools are unrelated (color utilities), so no sibling differentiation needed.
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 advises 'Use this rather than converting case by hand,' providing a clear context for when to use the tool. However, it does not specify when not to use it or mention alternative tools (though none exist in siblings for text transformation). The guidance is sufficient but lacks exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
9 tool updates
v1.0.0- First observed
color_difference - First observed
contrast_check - First observed
convert_color - First observed
generate_harmony - First observed
get_palette - First observed
list_palettes - First observed
mix_colors - First observed
save_palette - First observed
transform_text
TDQS
A3.9/5.0
Disambiguation3/5
Most tools have clear, distinct purposes related to color operations. However, the inclusion of 'transform_text' is unrelated to color and could confuse agents about the server's domain. Palette retrieval tools (get_palette, list_palettes) are similar but distinct.
Naming Consistency4/5
All tool names consistently use the verb_noun pattern in snake_case (e.g., 'convert_color', 'list_palettes'). The exception is 'transform_text', which breaks the pattern both in verb domain and object, but the naming style is still consistent.
Tool Count4/5
With 9 tools, the server covers a reasonable scope of color operations plus palette management. The count is slightly elevated due to the unrelated 'transform_text' tool, but overall it's well-scoped for a color utility server.
Completeness3/5
The server provides core color functionalities (difference, contrast, conversion, harmony, mixing) and palette CRUD with save/update and get/list, but lacks a delete palette operation. The inclusion of 'transform_text' is a significant gap as it is outside the color domain and does not contribute to completeness.
Maintenance
ActivityActive
ResponsivenessNo issues
Resources
Unclaimed servers have limited discoverability.
Looking for Admin?
If you are the server author, to access and configure the admin panel.
Related MCP Connectors
Convert colours between hex, RGB, HSL, OKLCH and CMYK, and compute harmonies.
AI-agent design tools: fonts, font recognition, palettes, color naming, contrast, code, SVG, CSS.
Developer utilities: color conversion, WCAG contrast, timestamps, UUIDs, and hashing.
500+ deterministic tools for AI agents: math, conversion, validation, hashing, encoding, date/time.
Related MCP Servers
- AlicenseBqualityDmaintenanceEnables comprehensive color manipulation, conversion between 22+ formats (HEX, RGB, HSL, CMYK, LAB, etc.), palette generation, gradient creation, and accessibility compliance checking. Supports framework-specific outputs for CSS, Swift, Android, Flutter, and Tailwind with high-precision conversions and visualization capabilities.25MIT
- AlicenseNot gradedqualityDmaintenanceProvides comprehensive color conversion, manipulation, analysis, and WCAG accessibility tools supporting multiple formats (hex, rgb, hsl, oklch, oklab) for design systems and web development.312MIT
- AlicenseNot gradedqualityDmaintenanceA comprehensive toolkit for color conversion, manipulation, and accessibility analysis supporting formats like OkLCH and WCAG compliance. It enables AI agents to manage design systems by generating harmonious palettes, transforming color spaces, and performing contrast checks.2MIT
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
MCP directory API
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/RNVizion/rnv-color-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server