MCP server for Uwarp — a directory of 500+ free browser UI tools.
This package exposes three local tools you can use from Cursor or Claude Desktop. No paid API key is required. Most Uwarp listings are third-party embeds; this server does not scrape or wrap them. Contrast and palette math run entirely on-device; search_tools reads a bundled local catalog (data/tools.json).
Tool | Purpose |
| WCAG 2.x contrast ratio + AA/AAA flags |
| HSL harmony palettes + |
| Search the local Uwarp tool catalog |
Author / context: Sherotree · https://uwarp.design · MIT
No clone needed. Add to your MCP client config (Cursor mcp.json, Claude Desktop, etc.):
{
"mcpServers": {
"uwarp": {
"command": "npx",
"args": ["-y", "uwarp-mcp"]
}
}
}Related MCP server: Colour Memory API
Node.js 18+
cd /path/to/uwarp-mcp
npm install
npm run buildnpm testIncludes a check that black-on-white contrast ≈ 21.
npm start
# or during development:
npm run devThe process speaks MCP over stdio (JSON-RPC on stdin/stdout). Log noise goes to stderr.
Variable | Notes |
| Reserved for a future Uwarp API. Ignored today — no paid key needed. |
mcp.json)Add to your Cursor MCP config (e.g. ~/.cursor/mcp.json or project .cursor/mcp.json). Point args at the built entry after npm run build:
{
"mcpServers": {
"uwarp": {
"command": "node",
"args": ["/ABSOLUTE/PATH/TO/uwarp-mcp/dist/index.js"]
}
}
}Example if the project lives at ~/code/uwarp-mcp (use the absolute path):
{
"mcpServers": {
"uwarp": {
"command": "node",
"args": ["/Users/you/code/uwarp-mcp/dist/index.js"]
}
}
}Restart Cursor (or reload MCP servers) after saving.
Edit the Claude Desktop config:
macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
Windows: %APPDATA%\Claude\claude_desktop_config.json
{
"mcpServers": {
"uwarp": {
"command": "node",
"args": ["/ABSOLUTE/PATH/TO/uwarp-mcp/dist/index.js"]
}
}
}Restart Claude Desktop after saving.
check_contrastInput
Field | Type | Description |
| string | Hex |
| string | Hex |
Output
{
"ratio": 21,
"aa_normal": true,
"aa_large": true,
"aaa_normal": true,
"aaa_large": true
}Uses WCAG 2.x relative luminance and contrast ratio thresholds (AA normal ≥ 4.5, AA large ≥ 3, AAA normal ≥ 7, AAA large ≥ 4.5).
generate_paletteInput
Field | Type | Default | Description |
| string | — | Seed hex |
|
|
| Harmony mode |
| number |
| Colors, 3–12 |
Output
{
"colors": [{ "name": "Mid Blue", "hex": "#3b82f6" }],
"css": ":root {\n --color-1: #3b82f6; /* Mid Blue */\n}"
}search_toolsInput
Field | Type | Default | Description |
| string | — | Search text |
| string | — | Optional filter (e.g. |
| number |
| Max results, 1–20 |
Output
{
"tools": [
{
"name": "Contrast Checker",
"summary": "…",
"url": "https://uwarp.design/tools/contrast-checker",
"category": "color"
}
]
}Note:
search_toolsuses the local catalog indata/tools.json(sample entries for development). It does not scrape uwarp.design at runtime.
uwarp-mcp/
├── data/tools.json # Local Uwarp catalog (~28 samples)
├── src/
│ ├── index.ts # MCP stdio entry
│ └── tools/
│ ├── check_contrast.ts
│ ├── generate_palette.ts
│ └── search_tools.ts
├── tests/
├── dist/ # After npm run build
├── package.json
├── tsconfig.json
├── LICENSE
└── README.mdMIT © Sherotree / Uwarp
Compute WCAG 2.x contrast ratio and AA/AAA pass flags for a foreground/background hex pair. Pure local math — no network.
| Name | Required | Description | Default |
|---|---|---|---|
| background | Yes | Background color as #RGB or #RRGGBB (e.g. #ffffff) | |
| foreground | Yes | Foreground color as #RGB or #RRGGBB (e.g. #000000) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. It helpfully discloses 'Pure local math — no network,' which signals a deterministic, side-effect-free, offline operation. However it says nothing about error behavior for malformed hex input or the exact shape/order of the returned flags, and there is no output schema to fall back on.
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 tight sentences with zero waste: the primary action leads, and the follow-on behavioral note ('no network') is short and load-bearing rather than filler.
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 pure-computation tool with fully documented parameters, the description covers purpose and the key non-functional trait. Minor gap: with no output schema, the 'AA/AAA pass flags' hint is the only clue about return contents, so an agent lacks full return-value detail, though the tool's complexity makes this acceptable.
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 parameters (foreground, background, with #RGB/#RRGGBB formats and examples) are already fully documented. The description only names them as a 'hex pair' and adds no format or constraint detail beyond the schema. Baseline 3 applies.
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 precise verb+resource: computes WCAG 2.x contrast ratio and AA/AAA pass flags for a hex pair. The sibling tools (generate_palette, search_tools) do entirely different jobs, so an agent can identify this tool's function without opening the schema.
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 implied by the description — you call it when you have a foreground/background pair and need contrast compliance — but there is no explicit when-to-use, prerequisite, or alternative statement (e.g. versus generate_palette). Minimum viable guidance only.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate a color palette from a seed hex using local HSL harmonies (analogous, complementary, triadic, mono). Returns named colors and a :root CSS snippet.
| Name | Required | Description | Default |
|---|---|---|---|
| seed | Yes | Seed color as #RGB or #RRGGBB | |
| count | No | Number of colors 3–12 (default: 6) | |
| harmony | No | Harmony mode (default: analogous) | analogous |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses that generation is 'local' and HSL-based (implying offline, deterministic computation) and what the output contains (named colors plus a :root CSS snippet). It says nothing about behavior on an invalid hex seed, whether the same seed always yields the same palette, or the count/harmony interaction.
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 tightly packed sentences: the first front-loads the core action and method, the second covers the return. No filler, no repetition of the tool name.
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?
There is no output schema, but the description compensates by naming the return shape (named colors and a :root CSS snippet). For a simple three-parameter generator that is largely complete; only edge-case behavior on bad input is left unspecified.
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 documents seed format, count range/default, and harmony values. The description repeats the harmony mode names and mentions the hex seed but adds no semantics beyond the schema (e.g. how count interacts with the harmony set). Baseline 3 applies.
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 ('Generate a color palette from a seed hex'), names the algorithm ('local HSL harmonies') and enumerates the supported modes. The siblings (search_tools, check_contrast) are functionally unrelated, so the agent can route to this tool without ambiguity.
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 implied by the purpose — you call it when you need a palette derived from a seed color — but there is no explicit guidance on when to prefer it over alternatives (e.g. check_contrast for accessibility validation) or when not to use it. 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.
Search the local Uwarp tool catalog (bundled JSON — no scraping). Filter by query and optional category; returns name, summary, url, category.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max results 1–20 (default: 8) | |
| query | Yes | Search text matched against name, summary, category, tags | |
| category | No | Optional category filter (e.g. color, svg-generators, image-conversion) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. It usefully discloses that the search is local/bundled with no scraping (implying no network side effects) and names the returned fields, but says nothing about result ranking, case sensitivity, or empty-result behavior.
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 tight sentence (with a parenthetical) front-loads the action and resource, then covers filtering and return shape. Every clause carries information; nothing is redundant or padded.
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 helpfully enumerates the returned fields (name, summary, url, category) and clarifies the local/no-scraping data source. It stops short of describing error or empty-result behavior, but is otherwise sufficient for correct 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 all three parameters (query, category, limit, including the 1-20 range and default) are already documented in the schema. The description only restates the filtering intent and adds no syntax or matching details beyond it, making the baseline 3 correct.
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 (search) and resource (the local Uwarp tool catalog), plus a clarifying constraint that it is a bundled JSON with no scraping. This is unambiguously distinct from siblings generate_palette and check_contrast, which are generators/validators rather than catalog lookups.
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 says to filter by query and optional category, which implies the usage pattern, but it never states when to use this tool or what the alternative would be. Since no sibling tool overlaps in purpose (a catalog search), the omission is minor but still leaves usage to inference.
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.
v1.0.0check_contrastgenerate_palettesearch_toolsScored across 3 tools
Each tool has a clearly distinct purpose: palette generation, catalog search, and contrast checking. There is no overlap between generating colors, searching tools, and evaluating contrast.
All three tools follow a consistent verb_noun snake_case pattern: generate_palette, search_tools, check_contrast. No deviations or mixed conventions.
Three tools is reasonable for a small utility server, but the surface spans two unrelated areas (color utilities and tool catalog search), leaving each sub-domain a bit thin. It is slightly under-scoped rather than excessive.
Color workflows cover palette generation and contrast checking but lack color format conversion or palette validation. The tool catalog only supports search with no operation to retrieve full tool details, leaving a notable gap.
AI-agent design tools: fonts, font recognition, palettes, color naming, contrast, code, SVG, CSS.
18 color tools: OKLCH, WCAG and APCA contrast fixes, palettes, gradients, color blindness, tokens.
Verified color tokens for AI coding agents: one brand hex in, WCAG/APCA-measured themes out.
Give your agent a real design system: tokens, measured WCAG contrast, and rules to follow.
