UI Craft
GitHubInstall the skill
Skip to content

MCP server

ui-craft-mcp exposes eight deterministic tools over the Model Context Protocol — task routing, anti-slop, token lint, acceptance bar, the composite score, and the two fold tools.

Updated 2026-08-05

ui-craft-mcp exposes eight deterministic tools over the Model Context Protocol (stdio transport). Works with Claude Desktop, Cursor, and any MCP-compatible client.

The MCP server is the checks layer — deterministic, rule-based, identical output for identical input. The skill is the taste layer — judgment, aesthetics, architecture. These never overlap: there are no taste rules in the server, and no rule-checks duplicated in the skill.

Tools

Tool What it does
route_task Routes a natural-language task to the references, commands and tools that cover it, plus the first move — pointers only, never rules
check_anti_slop 43-rule anti-slop scanner via scan() from ui-craft-detect — in-process, no subprocess
tokens_lint Off-system token detector: raw hex colors, non-scale radius/spacing px, magic z-index
acceptance_bar Acceptance checklist for a UI surface (dashboard, landing, auth, generic) — data only, no scoring
ux_coverage The parts a screen archetype needs to be complete, across 12 archetypes — the completeness axis, reported beside distinction and never folded into a score
score_ui Composite UICraftScore (0-100 + grade + per-dimension subscores) — all three dimensions in one call
fold_candidates Draws landing-fold composition classes, preferring ones the project has not spent yet
check_fold Renders a URL and reports what its fold actually is — screenshot, composition class, drift, invariants

Most tools accept either a code string (inline source) or a path (file or directory), and return structured JSON findings + a summary. route_task takes a prompt, acceptance_bar and ux_coverage take a surface or archetype name, and check_fold takes a URL.

Why route_task exists

The routing table in the skill only fires when your words match our filenames. Ask for “an analytics panel” and nothing points at recipe-dashboard.md, because that file never says analytics. route_task closes the gap with a synonym map, and by indexing entries under the parts they are built from — so “pricing block” reaches the landing recipe.

It returns pointers, never rules: the design judgment stays in the files it points at.

Quick start

Wire it into your project’s .mcp.json:

{ "mcpServers": { "ui-craft": { "command": "npx", "args": ["-y", "ui-craft-mcp@0.9.0"] } } }

The version is pinned on purpose. Every launcher ui-craft generates or documents uses an immutable package spec, declared in distribution-manifest.json — an unpinned npx resolves to whatever is newest at first run, which is how an install silently changes behaviour between two machines.

Then your MCP client can call the tools directly — for example, gate a build by calling score_ui on a changed file and checking the grade.

Boundary, restated

  • Deterministic. Same input → same output, every run. Safe to gate CI on.
  • No judgment. Aesthetic and architectural decisions stay in the skill and the /heuristic command. The judged UsabilityScore is computed by the host agent, not by this server.

Source

Spotted something out of date? Open an issue on GitHub →