Server runs on Node.js, allowing for color scheme generation with various modes and formats (Hex, RGB, HSL) through the MCP protocol.
Click on "Deploy 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., "@Color Scheme Generator MCP Server create a complementary palette using #ff6b35 with 7 colors"
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.
This is a Model Context Protocol (MCP) server that generates harmonious color schemes using The Color API. It provides multiple color scheme generation tools for creating beautiful and cohesive color palettes for design projects.
The server provides 8 different color scheme generation tools:
Monochrome Schemes: Variations of a single hue
Standard monochrome
Dark monochrome
Light monochrome
Color Wheel Based Schemes:
Analogic: Adjacent colors on the color wheel for harmonious designs
Complement: Opposite colors for high contrast
Analogic Complement: Combination of analogic and complement
Triad: Three evenly spaced colors for balanced palettes
Quad: Four evenly spaced colors for diverse palettes
Related MCP server: MCP Color Converter
Node.js (v18 or later)
npm, yarn, or pnpm
An MCP client (e.g., Claude Desktop, Cursor)
Clone and install dependencies:
git clone <repository-url>
cd colors-mcp-server
npm installBuild the server:
npm run buildConfigure your MCP client:
For Claude Desktop (claude_desktop_config.json):
{
"mcpServers": {
"color-scheme-generator": {
"command": "node",
"args": ["/full/path/to/colors-mcp-server/build/index.js"]
}
}
}For Cursor:
Go to Settings > MCP > Add new global MCP server
Use the same configuration as above
The server accepts colors in multiple formats:
Hex: "098765" or "#098765"
RGB: "0,71,171" or "rgb(0,71,171)"
HSL: "215,100%,34%" or "hsl(215,100%,34%)"
color: The seed color (required)
count: Number of colors to generate (optional, default: 5, range: 3-10)
generate_monochrome_scheme
generate_monochrome_dark_scheme
generate_monochrome_light_scheme
generate_analogic_scheme
generate_complement_scheme
generate_analogic_complement_scheme
generate_triad_scheme
generate_quad_scheme
Ask your MCP client:
"Generate a monochrome color scheme from blue"
"Create a complementary palette using #ff6b35 with 7 colors"
"I need an analogic scheme from rgb(120,80,200)"
Each tool returns a structured JSON with:
Scheme mode and seed color
Array of generated colors with hex, RGB, HSL values
Color names and positions
Use the MCP Inspector to debug:
npx @modelcontextprotocol/inspector node ./build/index.jssrc/index.ts: Main server entry point
src/tools/index.ts: Color scheme generation tools
src/prompts/index.ts: Usage guidance prompts
build/: Compiled TypeScript output
Generates an analogic complement color scheme
| Name | Required | Description | Default |
|---|---|---|---|
| color | Yes | The seed color in hex (098765), RGB (0,71,171), or HSL (215,100%,34%) format | |
| count | No | Number of colors to generate (3-10, default: 5) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states what the tool does but doesn't describe how it works—no information about algorithm, output format, whether it's deterministic, performance characteristics, or error handling. For a generative tool with zero annotation coverage, this leaves significant behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that states the core functionality without any wasted words. It's appropriately sized for a tool with two well-documented parameters and gets straight to the point with no unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of color scheme generation, no annotations, and no output schema, the description is insufficient. It doesn't explain what 'analogic complement' means, what the output looks like (e.g., array of colors), or how the generation algorithm works. For a creative tool with multiple sibling alternatives, more context is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, with both parameters ('color' and 'count') fully documented in the schema. The description adds no parameter information beyond what's already in the schema, so it meets the baseline of 3 where the schema does the heavy lifting but doesn't provide additional semantic context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('generates') and resource ('analogic complement color scheme'), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'generate_analogic_scheme' or 'generate_complement_scheme', which would require explaining what makes 'analogic complement' distinct from those alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus the seven sibling tools listed. There's no mention of what 'analogic complement' means, when it's appropriate compared to other schemes, or any prerequisites for use. The agent must infer usage from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generates an analogic color scheme with adjacent colors on the color wheel
| Name | Required | Description | Default |
|---|---|---|---|
| color | Yes | The seed color in hex (098765), RGB (0,71,171), or HSL (215,100%,34%) format | |
| count | No | Number of colors to generate (3-10, default: 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 core behavior (generating a color scheme) but lacks details on output format, whether it's deterministic, error handling, or performance traits. It's adequate but minimal for a generation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the key action and differentiator. Every word earns its place with no redundancy or fluff, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (generation with parameters), no annotations, and no output schema, the description is minimally complete. It covers the purpose and basic behavior but lacks details on output (e.g., format of returned colors) or advanced usage, leaving gaps for the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents both parameters. The description adds no parameter-specific semantics beyond what the schema provides, meeting the baseline for high coverage without extra value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Generates') and resource ('an analogic color scheme'), and distinguishes it from siblings by specifying 'adjacent colors on the color wheel' (unlike complement, triad, quad, or monochrome schemes). It provides a precise functional definition.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage through 'adjacent colors on the color wheel,' suggesting when to use it (for harmonious, analogous palettes) versus alternatives like complement or triad schemes. However, it lacks explicit guidance on when-not-to-use or named alternatives, leaving some interpretation to the agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generates a complementary color scheme with opposite colors on the color wheel
| Name | Required | Description | Default |
|---|---|---|---|
| color | Yes | The seed color in hex (098765), RGB (0,71,171), or HSL (215,100%,34%) format | |
| count | No | Number of colors to generate (3-10, default: 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 of behavioral disclosure. It states the tool 'Generates a complementary color scheme,' implying a read-only operation, but doesn't address key behavioral aspects such as whether it's deterministic, how it handles invalid color inputs, potential rate limits, or what the output format looks like (e.g., list of colors in a specific format). For a tool with no annotation coverage, this is a significant gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence: 'Generates a complementary color scheme with opposite colors on the color wheel.' It's front-loaded with the core purpose and includes no redundant or unnecessary information, making it highly concise and well-structured for quick understanding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (generating color schemes with two parameters), no annotations, and no output schema, the description is minimally adequate. It explains what the tool does but lacks details on output format, error handling, or behavioral traits. Without annotations or an output schema, the description should do more to compensate, but it provides only basic functionality, leaving gaps in completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, with both parameters ('color' and 'count') fully documented in the schema. The description adds no additional parameter information beyond what's in the schema. According to the rules, when schema coverage is high (>80%), the baseline score is 3 even with no param info in the description, which applies here as the description doesn't compensate or add meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Generates a complementary color scheme with opposite colors on the color wheel.' It specifies the verb ('Generates') and resource ('complementary color scheme'), and the 'opposite colors on the color wheel' phrase provides useful context. However, it doesn't explicitly differentiate from sibling tools like 'generate_analogic_complement_scheme' or 'generate_triad_scheme', which likely generate different types of color schemes, so it falls short of a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus its siblings. With multiple sibling tools for generating color schemes (e.g., 'generate_analogic_complement_scheme', 'generate_triad_scheme'), the agent lacks explicit direction on selecting this specific complementary scheme tool. There's no mention of alternatives, prerequisites, or typical use cases, leaving usage decisions ambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generates a dark monochrome color scheme
| Name | Required | Description | Default |
|---|---|---|---|
| color | Yes | The seed color in hex (098765), RGB (0,71,171), or HSL (215,100%,34%) format | |
| count | No | Number of colors to generate (3-10, default: 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 of behavioral disclosure. While 'generates' implies a creation operation, it doesn't disclose important behavioral traits such as whether this is deterministic, what format the output takes, whether it's idempotent, or any performance characteristics. The description is too minimal for a mutation-like tool with no annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that states the core purpose without any wasted words. It's appropriately sized for a simple generation tool and gets straight to the point with no unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no annotations and no output schema, the description is insufficiently complete. It doesn't explain what the output looks like (e.g., array of colors, CSS object), doesn't mention any constraints or edge cases, and provides no context about the algorithm or quality of results. Given the lack of structured metadata, the description should do more to compensate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, with both parameters well-documented in the schema itself. The description adds no additional parameter semantics beyond what's already in the schema (e.g., it doesn't explain the relationship between color and count, or provide examples of typical values). This meets the baseline expectation when schema coverage is complete.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'generates' and the resource 'dark monochrome color scheme', making the purpose immediately understandable. However, it doesn't distinguish this tool from its sibling 'generate_monochrome_scheme' or 'generate_monochrome_light_scheme', which would require explicit differentiation to earn a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With multiple sibling tools for generating different color schemes (e.g., analogic, complement, triad), there's no indication of when a dark monochrome scheme is appropriate versus other types, nor any mention of prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generates a light monochrome color scheme
| Name | Required | Description | Default |
|---|---|---|---|
| color | Yes | The seed color in hex (098765), RGB (0,71,171), or HSL (215,100%,34%) format | |
| count | No | Number of colors to generate (3-10, default: 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 of behavioral disclosure. It states what the tool does but lacks details on output format, error handling, or any behavioral traits like performance or constraints. This leaves significant gaps for an agent to understand how to use it effectively.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no wasted words. It is front-loaded and directly states the tool's purpose, making it easy to parse and understand quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, the description is incomplete. It doesn't explain what the tool returns (e.g., a list of colors, a scheme object) or any behavioral aspects, which are crucial for an agent to invoke it correctly in a broader context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the input schema already fully documents the parameters. The description adds no additional meaning beyond what the schema provides, such as explaining the relationship between 'color' and 'count' or typical use cases. Baseline 3 is appropriate when the schema handles parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with a specific verb ('generates') and resource ('light monochrome color scheme'), making it understandable. However, it doesn't explicitly differentiate from its sibling 'generate_monochrome_scheme' or 'generate_monochrome_dark_scheme', which would be needed for a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With multiple sibling tools for generating color schemes, there is no mention of specific contexts, exclusions, or comparisons to help an agent choose appropriately.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generates a monochrome color scheme with variations of a single hue
| Name | Required | Description | Default |
|---|---|---|---|
| color | Yes | The seed color in hex (098765), RGB (0,71,171), or HSL (215,100%,34%) format | |
| count | No | Number of colors to generate (3-10, default: 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 of behavioral disclosure. It states the tool generates a color scheme but does not explain what the output looks like (e.g., list of colors, format), whether it's deterministic, or if there are any side effects (e.g., caching). For a generation tool with no annotation coverage, this lack of detail is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose without unnecessary words. It is front-loaded with the core action and constraint, making it easy to understand at a glance. Every part of the sentence earns its place by conveying essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (generation with two parameters) and no output schema, the description is minimally adequate. It covers the basic purpose but lacks details on output format, behavioral traits, and usage context. With no annotations and incomplete behavioral transparency, it falls short of being fully helpful for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already fully documents both parameters ('color' and 'count'). The description does not add any meaning beyond what the schema provides, such as explaining how the seed color influences variations or the aesthetic impact of the count. Baseline 3 is appropriate when the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Generates a monochrome color scheme with variations of a single hue.' It specifies the verb ('generates'), resource ('monochrome color scheme'), and key constraint ('variations of a single hue'). However, it does not explicitly differentiate from sibling tools like 'generate_monochrome_dark_scheme' or 'generate_monochrome_light_scheme', which likely produce similar monochrome schemes with specific brightness variations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention sibling tools or contexts where a monochrome scheme is preferred over other types (e.g., complement or triad schemes). Without such guidance, users must infer usage based on the tool name alone, which is insufficient for optimal selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generates a quad color scheme with four evenly spaced colors on the color wheel
| Name | Required | Description | Default |
|---|---|---|---|
| color | Yes | The seed color in hex (098765), RGB (0,71,171), or HSL (215,100%,34%) format | |
| count | No | Number of colors to generate (3-10, default: 5) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only states what the tool does (generates colors) without covering aspects like performance (e.g., speed, rate limits), error handling, or output format details. This is a significant gap for a tool with no structured behavioral hints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose without any wasted words. It directly conveys the tool's function and key output characteristic, making it easy for an agent to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (generating color schemes) and lack of annotations or output schema, the description is minimally adequate. It specifies the scheme type and basic output but omits details like return format (e.g., array of hex codes), error cases, or performance considerations, which could hinder effective tool invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents both parameters (color format options and count range). The description adds no additional parameter semantics beyond what the schema provides, such as explaining how the seed color influences the quad scheme or clarifying the 'count' parameter's relevance to 'four evenly spaced colors'. Baseline 3 is appropriate as the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('generates') and resource ('quad color scheme'), with precise details about the output ('four evenly spaced colors on the color wheel'). It effectively distinguishes from sibling tools by specifying the 'quad' scheme type, which is unique among the listed alternatives (e.g., triad, complement, monochrome).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus the sibling alternatives. It does not mention any context, prerequisites, or exclusions for selecting a quad scheme over other color schemes like triad or complement, leaving the agent to infer usage based on the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generates a triad color scheme with three evenly spaced colors on the color wheel
| Name | Required | Description | Default |
|---|---|---|---|
| color | Yes | The seed color in hex (098765), RGB (0,71,171), or HSL (215,100%,34%) format | |
| count | No | Number of colors to generate (3-10, default: 5) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool generates colors but doesn't cover aspects like whether it's deterministic, if there are rate limits, error handling for invalid inputs, or the format of the output (e.g., list of hex codes). This leaves significant gaps for an agent to understand how to invoke it effectively.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose without unnecessary details. Every word earns its place by specifying the tool's function and key characteristic (three evenly spaced colors), making it easy to scan and understand quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a color generation tool with no annotations and no output schema, the description is insufficient. It doesn't explain the return values (e.g., format of generated colors), error conditions, or behavioral traits like idempotency. For a tool that likely produces structured color data, more context is needed to ensure reliable agent usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the input schema already fully documents the parameters 'color' and 'count'. The description adds no additional meaning beyond what the schema provides, such as explaining how 'color' influences the triad generation or clarifying the relationship between 'count' and the triad concept. Baseline 3 is appropriate when the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Generates') and resource ('a triad color scheme'), specifying it produces 'three evenly spaced colors on the color wheel'. However, it doesn't explicitly differentiate from sibling tools like 'generate_quad_scheme' or 'generate_complement_scheme', which would require mentioning the specific triad pattern versus other color schemes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description lacks context about scenarios where a triad scheme is preferred over monochrome, complementary, or other sibling schemes, and there are no exclusions or prerequisites mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
generate_analogic_complement_schemegenerate_analogic_schemegenerate_complement_schemegenerate_monochrome_dark_schemegenerate_monochrome_light_schemegenerate_monochrome_schemegenerate_quad_schemegenerate_triad_schemeScored across 8 tools
Every tool has a clearly distinct purpose based on specific color scheme types (e.g., analogic, complement, monochrome, quad, triad), with no overlap in functionality. The descriptions precisely differentiate each scheme's generation logic, making misselection unlikely.
All tool names follow a consistent 'generate_[scheme_type]_scheme' pattern with snake_case throughout, using descriptive adjectives (e.g., analogic_complement, monochrome_dark) to specify variations. This uniformity aids predictability and readability.
With 8 tools, the server is well-scoped for generating various color schemes, covering common types like monochrome, complementary, and triad. Each tool earns its place by addressing a distinct scheme, avoiding bloat or thin coverage.
The tool set comprehensively covers major color scheme types (e.g., monochrome, complementary, triad, quad, analogic) with light/dark variations for monochrome. A minor gap exists in lacking tools for custom inputs or adjustments (e.g., modifying schemes), but core generation is complete.
Convert colours between hex, RGB, HSL, OKLCH and CMYK, and compute harmonies.
Color API MCP — wraps thecolorapi.com (free, no auth)
A complete color workflow over MCP: mix, convert, harmonize, measure, and remember palettes.
Generate styled PNG/SVG map images of any location with 11 customizable color themes.