color-palette
Server Details
Cloudflare Workers MCP server: color-palette
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
- Repository
- lazymac2x/color-palette-api
- GitHub Stars
- 0
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Tool Definition Quality
Average 3.8/5 across 7 of 7 tools scored.
Each tool targets a distinct aspect of color manipulation (contrast, harmony, conversion, CSS generation, gradient, Tailwind, random palette) with no overlapping purposes.
All tool names follow a consistent verb_noun snake_case pattern (e.g., check_contrast, generate_css), making them predictable and easy to distinguish.
7 tools is well-scoped for a color palette server, covering essential operations without being overwhelming or insufficient.
The tool set covers core color workflows (conversion, harmony, contrast, CSS output, gradient, Tailwind) but lacks color mixing/adjustment operations, which is a minor gap.
Available Tools
7 toolscheck_contrastAInspect
Check WCAG 2.1 contrast ratio between foreground and background colors. Returns ratio and AA/AAA pass/fail for both normal and large text.
| Name | Required | Description | Default |
|---|---|---|---|
| background | Yes | Background hex color | |
| foreground | Yes | Foreground hex color |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must convey behavioral traits. It adequately describes the tool as a stateless computation that returns ratio and pass/fail results. It does not list potential side effects or constraints, but for a simple calculation tool, the description is sufficiently transparent.
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 extremely concise with two sentences, no redundancy, and front-loads the core action ('Check WCAG 2.1 contrast ratio'). Every word serves a purpose.
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 simple contrast-checking tool with two parameters fully documented in the schema, the description fully covers the output (ratio and AA/AAA pass/fail). No additional context is necessary given the low complexity and absence of output schema.
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% (both parameters have descriptions). The tool description adds minimal extra meaning beyond stating 'foreground and background colors,' which aligns with param names. No additional guidance on format or constraints is provided, but the existing schema is adequate.
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 checks WCAG 2.1 contrast ratio, specifies the inputs (foreground/background colors), and describes the output (ratio and AA/AAA pass/fail). It uniquely identifies the tool's function among siblings like color_harmony 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.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide explicit guidance on when to use this tool versus alternatives like color_harmony or generate_css. However, the distinct purpose implies usage for contrast checking, but no exclusionary or preferential context is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
color_harmonyBInspect
Generate a set of harmonious colors from a base hex color. Harmony types: complementary, analogous, triadic, split, tetradic, monochromatic.
| Name | Required | Description | Default |
|---|---|---|---|
| type | Yes | Harmony type | |
| color | Yes | Base hex color, e.g. "#ff5733" | |
| count | No | Number of colors for monochromatic only (2–10, default 5) |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It only states the basic function but does not mention side effects, error handling, permissions, or output format (e.g., array of hex codes).
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 concise with two sentences that front-load the purpose and list harmony types. No unnecessary words.
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?
The tool is relatively simple with 3 parameters and no output schema. The description covers the core functionality but lacks details on output format and error handling, making it adequate but not fully complete.
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 coverage is 100% and all parameters have descriptions. The description lists harmony types again but adds little new meaning beyond the schema. Baseline 3 is appropriate.
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 generates harmonious colors from a base hex color and lists all allowed harmony types. It distinguishes itself from siblings like check_contrast, convert_color, etc., which have different purposes.
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 does not provide guidance on when to use this tool versus alternatives, nor does it specify when not to use it. Only implicit usage can be inferred from the description.
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 hex color to HEX, RGB, HSL, and CMYK formats. Input: hex string with or without # (e.g. "ff5733").
| Name | Required | Description | Default |
|---|---|---|---|
| color | Yes | Hex color string, e.g. "ff5733" or "#ff5733" |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. The description does not disclose behavioral traits such as handling of invalid inputs, response format, or whether the conversion is deterministic. For a simple conversion, the minimum viable is present but could be improved.
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 two concise sentences with no wasted words. The purpose is front-loaded and every sentence adds value.
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 simplicity of the tool (one parameter, no output schema, no annotations), the description adequately covers the input format and output goal. It could mention what happens on invalid input or the exact output structure, but it is mostly complete.
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 coverage is 100% and the description adds marginal value by mentioning that the input can include or omit the '#', and listing output formats. However, the schema already describes the parameter as a hex color string with examples. Baseline 3 is appropriate.
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 'convert' and the resource 'hex color', and explicitly lists the output formats (HEX, RGB, HSL, CMYK). This distinguishes it from sibling tools like check_contrast or generate_css, which serve different purposes.
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 by stating what the tool does, but does not explicitly say when to use it versus alternatives or when not to use it. For a simple conversion tool, this is adequate but lacks explicit guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
generate_cssAInspect
Generate CSS :root custom properties from a list of hex colors. Returns a ready-to-paste CSS block.
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | CSS variable prefix (default: "palette") | |
| colors | Yes | Array of hex color strings |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
In the absence of annotations, the description clearly indicates the tool generates and returns a CSS block, implying a non-destructive, computational action. It does not explicitly state it has no side effects, but the generative nature is evident.
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 sentence with a clear action and result. Every word is substantive, and the output format is front-loaded. No wasted content.
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?
The description explains the input and output sufficiently for the low complexity of the tool. It does not detail error handling or edge cases, but the ready-to-paste CSS block is a clear expectation. The lack of output schema is partly compensated by stating the return type.
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?
Both parameters have descriptions in the schema (100% coverage). The description adds context about the overall purpose but doesn't enhance parameter details beyond what the schema provides. The default for 'name' is acknowledged in the schema description.
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 generates CSS :root custom properties from hex colors and returns a CSS block. It distinguishes itself from sibling tools like color conversion or gradient generation by focusing on CSS variable output.
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 for creating CSS custom properties but does not explicitly state when to use this tool over alternatives like generate_tailwind or how to avoid misuses. No exclusion criteria or prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
generate_gradientAInspect
Generate an interpolated gradient between two hex colors. Returns color stops and a ready-to-use CSS linear-gradient string.
| Name | Required | Description | Default |
|---|---|---|---|
| steps | No | Number of gradient stops (2–20, default 5) | |
| color1 | Yes | Start hex color | |
| color2 | Yes | End hex color |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully convey behavioral traits. It mentions the return format (color stops and CSS string) but does not disclose potential side effects, rate limits, or resource impact. It is adequate but incomplete.
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 extremely concise, using two distinct clauses to cover input and output. Every word adds value, and it is front-loaded with the action verb.
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?
With no output schema and no annotations, the description should provide more context about the return format or constraints. It only mentions 'color stops' and 'CSS string' without details, 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 baseline is 3. The description adds minimal extra meaning beyond the schema, only summarizing that it uses two colors. The `steps` parameter is not elaborated further.
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?
Description clearly states the tool generates an interpolated gradient between two hex colors and returns color stops and a CSS string. It distinguishes itself from sibling tools like check_contrast and color_harmony.
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 does not provide explicit guidance on when to use this tool versus alternatives. The purpose is clear from the name, but no context or exclusions are given, limiting the agent's ability to decide.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
generate_tailwindAInspect
Generate a Tailwind CSS color config object. Colors are mapped to standard shades (50, 100, 200 … 900) in order. Paste the result into tailwind.config.js theme.extend.colors.
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | Color group key (default: "brand") | |
| colors | Yes | Array of hex color strings (up to 10) |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that colors are mapped to standard shades and the output format, but does not mention validation of hex colors, handling of invalid inputs, or the maximum of 10 colors (which is only in the schema). With no annotations, more behavioral details would be helpful.
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?
Two sentences, no redundant words. Purpose and usage are front-loaded. Every sentence adds value.
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?
The description covers the output purpose and how to use it, despite no output schema. It lacks error handling information or examples, but for a simple config generator it is reasonably complete.
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 coverage is 100%, so baseline is 3. The description adds minimal extra meaning, such as clarifying that 'name' is a color group key with default 'brand'. It does not elaborate on the 'colors' array beyond what the schema says.
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 that the tool generates a Tailwind CSS color config object, specifying the mapping to standard shades. This distinguishes it from siblings like 'random_palette' or 'generate_css' which have different outputs.
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 tells the user to paste the result into tailwind.config.js theme.extend.colors, which is direct usage guidance. However, it does not explicitly differentiate when to use this tool versus alternatives like 'color_harmony' or 'check_contrast', though the context implies its purpose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
random_paletteAInspect
Generate a random harmonious color palette. Colors share a hue family to avoid clashing.
| Name | Required | Description | Default |
|---|---|---|---|
| count | No | Number of colors (1–10, default 5) |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries burden. It discloses that colors share a hue family (a behavioral trait), but does not state whether the tool is read-only, has side effects, or requires permissions. Adequate for a generative tool but could be more explicit.
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?
Two concise sentences front-loading the action and key property. No redundant words, efficiently 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?
With one parameter and no output schema or annotations, the description covers the essential behavior. Could mention return format or color representation, but likely adequate for a simple generation tool.
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 coverage is 100% with one parameter ('count') fully described. Description does not add parameter-level meaning beyond the schema. Baseline 3 is appropriate.
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?
Description clearly states the action ('Generate'), resource ('random harmonious color palette'), and key property ('Colors share a hue family to avoid clashing'). Distinguishes from siblings like check_contrast or color_harmony.
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 explicit guidance on when to use this tool vs alternatives. Does not mention exclusions, prerequisites, or comparisons to sibling tools like generate_gradient or convert_color.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
Discussions
No comments yet. Be the first to start the discussion!