This server lets you discover and use PaletteGet color palettes through MCP tools.
List palettes, optionally filtered by platform (app / web / miniapp) and tag, with a configurable result limit.
Retrieve a palette’s full details by slug: role colors, contrast results, and pairing advice.
Recommend palettes from natural-language keywords in English or Chinese, showing what matched.
Get ready-to-paste CSS custom properties for a chosen palette.
Provides CSS custom properties for a palette, including semantic variable names, ready to paste into a project.
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., "@PaletteGet MCP Server suggest a dark finance dashboard palette and give me the CSS variables"
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.
An MCP server for the PaletteGet color palette library: 100 palettes across App, Web and Mini App UIs, each organized into 10 design roles and checked against WCAG contrast requirements.
It exists so your AI coding tool stops inventing hex values. Instead of guessing, the model calls a tool and gets the real role colors, the measured contrast ratios, and the pairing advice that ships with the palette.
No API key, no sign-up.
https://paletteget-mcp.y7206062.workers.dev/mcp{
"mcpServers": {
"paletteget": {
"type": "http",
"url": "https://paletteget-mcp.y7206062.workers.dev/mcp"
}
}
}ChatGPT: Settings → Connectors → Add custom connector → paste the URL.
The hosted server embeds the dataset at deploy time, so it never depends on the site being reachable and answers in a few milliseconds.
Related MCP server: Color Palette Generator MCP App
npx -y paletteget-mcp{
"mcpServers": {
"paletteget": {
"command": "npx",
"args": ["-y", "paletteget-mcp"]
}
}
}Behind a proxy, set PALETTEGET_PROXY=http://127.0.0.1:7897 in the server's env block.
git clone https://github.com/yang7206/paletteget-mcp.git
cd paletteget-mcp
npm install{
"mcpServers": {
"paletteget": {
"command": "node",
"args": ["/absolute/path/to/paletteget-mcp/index.mjs"]
}
}
}The stdio server fetches live data from the public JSON endpoints and caches it for 10 minutes.
Tool | What it does |
| List palettes, optionally filtered by platform ( |
| Full data for one palette: role colors, contrast results, human-written pairing advice |
| Recommend palettes from keywords in English or Chinese, and say what matched |
| CSS custom properties for a palette, ready to paste |
| WCAG contrast between any two colors, with both the body-text and large-text verdicts |
| Readable text colors for a given background: same-hue tints and shades plus black and white, ranked by contrast |
| Derive a dark-mode version of a light palette with published rules, and the measured contrast of every pair |
| Paste-ready code for one palette: Android |
| Expand one base color into a 50 to 900 scale, with white and black contrast per step; JSON, CSS or Tailwind output |
Example call and result:
suggest_palette { "query": "dark finance dashboard", "limit": 2 }
- Ink Blue Night / 墨蓝夜（app，分 94）
slug: mo-lan-ye 主色: #4c8df6
场景: Finance & analytics apps (dark mode)
命中: 标签:dark, 场景:financeVariable | Default | Purpose |
|
| Override the dataset URL |
| derived ( | Override the Chinese dataset URL |
|
| Cache lifetime in milliseconds |
| none | Route requests through a proxy, e.g. |
Behind a firewall, Node's built-in fetch ignores the usual proxy variables, so set
PALETTEGET_PROXY explicitly.
npm run smokeThe smoke test speaks the MCP stdio protocol directly and exercises every tool against a local
fixture, so it runs offline. Point PALETTEGET_API at the live site to test against production.
The worker (worker.mjs) is a hand-written, stateless subset of MCP Streamable HTTP
(initialize, tools/list, tools/call, ping) with no SDK dependency, which keeps it small and
Workers-native.
# 1. Regenerate the embedded dataset (run both locales)
SITE_URL=https://paletteget.com SITE_LOCALE=zh node --import ./alias-loader.mjs build-data.mjs
SITE_URL=https://paletteget.com SITE_LOCALE=en node --import ./alias-loader.mjs build-data.mjs
# 2. Local check
npx wrangler dev # POST JSON-RPC to http://127.0.0.1:8787/mcp
# 3. Deploy (needs CLOUDFLARE_API_TOKEN with Workers Scripts:Edit)
npx wrangler deploybuild-data.mjs reuses the site's own i18n modules through alias-hooks.mjs, so names, scenes and
advice stay identical to the published site. data/ is generated at build time and never committed.
Code is MIT (see LICENSE). Palette data comes from paletteget.com and
may be reused freely in personal and commercial projects; a credit link is appreciated.
Machine-readable forms of the same data, if you would rather skip MCP entirely:
Full dataset: https://paletteget.com/api/index.json
One palette: https://paletteget.com/palette-list/{platform}/{slug}/index.json
CSS variables: https://paletteget.com/palette-list/{platform}/{slug}/index.css
Agent guide: https://paletteget.com/llms.txt
取一套配色的 CSS 自定义属性（可直接粘进项目），含语义化变量名。
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | 配色 slug | |
| platform | No |
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 conveys the output shape (CSS custom properties with semantic names) but says nothing about read-only status, required auth, whether an invalid slug errors or falls back, or per-platform output differences — a significant gap for an unannotated 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?
A single compact sentence that front-loads the resource and the key output characteristic. Nothing is padded, though it is arguably undersized given the undocumented platform parameter.
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, the description partially compensates by characterizing the return value (CSS custom properties, semantic names, paste-ready). But it omits any explanation of the platform parameter's effect and any routing guidance among the three sibling palette tools, leaving the definition only minimally viable.
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 only 50%: 'slug' is briefly glossed as '配色 slug' while 'platform' has an enum but no description at all. The tool description never mentions either parameter, so it does not compensate for the documentation gap — notably, nothing explains what selecting 'app' vs 'web' vs 'miniapp' does to the output.
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?
States a specific verb and resource: retrieving CSS custom properties for a color scheme, with the useful detail that they are directly pasteable and semantically named. It is clear what the tool returns, though it never distinguishes itself from the sibling get_palette, leaving the agent to infer that this one is the CSS-format export variant.
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 parenthetical '(可直接粘进项目)' implies a usage context (export-ready CSS for embedding in a project), which hints at when to prefer this over get_palette. However, there is no explicit when-to-use statement, no when-not-to-use, and no reference to any sibling tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
取某一套配色的完整数据：角色色值（主色 / 功能色 / 中性色）、对比度、人工搭配建议。
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | 配色 slug，如 jing-hu-lan | |
| platform | No | 平台，不填则在三端中查找该 slug |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. It does disclose the shape of the returned content (roles, contrast, human pairing advice), which is genuinely useful given there is no output schema, but it says nothing about read-only semantics, permission needs, or behavior on a nonexistent slug.
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?
A single front-loaded sentence with a colon-delimited payload list; nothing is padded. It is efficient, though the brevity leaves little room for the routing and behavioral context an unannotated tool needs.
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 two-parameter read tool with no annotations and no output schema, the description covers what comes back but omits error behavior for an unknown slug and any guidance on the platform parameter's fallback. It is adequate but not 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 description coverage is 100%, so both slug and the platform enum are already documented in the schema, making 3 the baseline. The description adds only the implied notion of retrieving complete data for a palette, not any new syntax or format detail for the parameters.
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 names a specific verb (取, retrieve) and resource (某一套配色, a single palette) and enumerates the payload (role color values, contrast, pairing suggestions), so it is clearly not list_palettes or suggest_palette. It never names those siblings, though, so the differentiation is inferable rather than explicit.
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?
Usage is only implied: the required slug signals that this is the lookup-by-identifier path, distinct from listing or generating. There is no statement of when to prefer it over get_css_variables (e.g. raw variables vs. curated palette data) or what to do when a slug is unknown.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
列出配色库中的配色，可按平台（app / web / miniapp）与标签过滤。返回名称、slug、主色、场景与标签。
| Name | Required | Description | Default |
|---|---|---|---|
| tag | No | 标签过滤，支持中英文，如 暗黑 / Dark | |
| limit | No | 最多返回几条，默认 10 | |
| platform | No | 平台，不填则三端都列 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Since there are no annotations, the description must carry the behavioral burden. It significantly adds value by detailing exactly what fields the agent can expect to receive in the response (name, slug, primary color, scene, and tag), providing vital structural context.
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 highly concise, using a single sentence to convey the tool's function, available filters, and the specific set of data fields returned. There is zero wasted 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?
For a simple filtering/listing tool, the description is completely adequate. It defines the available parameters and clearly states the structure of the expected output data fields, leaving no critical operational 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%, setting a baseline of 3. The description reinforces the filtering functionality (platform and tag) and the default scope ('if not filled, all three are listed'), but it does not add critical semantic meaning beyond what the existing schema parameters already define.
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 uses a clear verb ('list') and specifies the resource ('color palettes in the library'). Crucially, it defines the operation as a listing and filtering task, distinguishing it from tools like get_palette or suggest_palette.
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 clearly outlines the mechanisms available for selecting data (filtering by platform and tag). This defines the scope of usage, implying its use for broad data retrieval rather than focused retrieval, though it does not explicitly state 'when not to use get_palette'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
按自然语言关键词推荐配色（中英文均可），例如「护眼的深色记账 App」「清新博客」。会说明每个结果命中了什么。
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | 最多返回几条，默认 5 | |
| query | Yes | 关键词，空格分隔，如「深色 记账」 | |
| platform | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It does disclose two useful behavioral facts: queries work in Chinese or English, and results explain what each match hit. It says nothing about determinism, whether results are cached palettes or generated, or any rate/limit behaviour beyond the schema's default.
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?
A single compact sentence with the core action front-loaded, followed by examples and one return-value note. No filler, though the examples and the '命中' note could be tightened.
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 read-only suggestion tool with no output schema and no annotations, the description should at least clarify the platform parameter's effect and what a returned suggestion contains. It covers the return semantics loosely ('会说明每个结果命中了什么') but leaves the platform dimension and result shape under-specified.
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 67%: query and limit are self-documented, but the platform enum (app/web/miniapp) is unexplained in both schema and description. The description does add real value by stating query accepts Chinese or English space-separated keywords, which goes beyond the schema's example.
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?
Names a specific verb (推荐) and resource (配色) plus the input modality (自然语言关键词), with two concrete examples that make the intent unambiguous. It does not explicitly contrast itself with the read-oriented siblings (get_palette, list_palettes, get_css_variables), so an agent must infer the keyword-vs-lookup distinction.
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 examples (「护眼的深色记账 App」) imply when this tool fits — when the user describes a mood or product rather than naming a palette — but there is no explicit 'use this instead of X when...' routing. No prerequisites or exclusions are stated.
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.
v0.1.0get_css_variablesget_palettelist_palettessuggest_paletteScored across 4 tools
list_palettes and suggest_palette both return palette sets, but the descriptions clearly separate filter-based browsing from natural-language recommendation with hit explanations. get_palette (full role data) and get_css_variables (CSS custom properties) differ in output format, though both take a palette identifier and could be momentarily confused.
All four names follow a uniform snake_case verb_noun pattern (list_, get_, suggest_, get_). The verbs accurately reflect the operation type, with no convention mixing.
Four tools is a tight, well-scoped surface for a read-only palette library. Each tool earns its place, though the set is on the thin side of the 3-15 range.
The surface covers the full consumption lifecycle: browse, inspect, recommend, and export to CSS. Minor gaps exist, such as searching by a specific color value or accessibility threshold, but core workflows have no dead ends.
Give your agent a real design system: tokens, measured WCAG contrast, and rules to follow.
Verified color tokens for AI coding agents: one brand hex in, WCAG/APCA-measured themes out.
Curated design references for AI — real CSS values, typography specs, and color palettes.
AI-agent design tools: fonts, font recognition, palettes, color naming, contrast, code, SVG, CSS.
