What can you do with this server?

The server is a design intelligence MCP server for AI coding agents, providing evidence-based design contracts, tokens, and audit plans from a curated catalog. It operates locally and deterministically without API keys or network access. Key capabilities: * Recommend design directions: Returns scored style candidates with reasons, rejected styles, secondary pairings, and confidence based on product context. * Compare design directions: Compares 2–4 styles across dimensions like product fit, density, and accessibility, without declaring a winner. * Design principle plans: Provides placement, application, verification steps, cautions, and relevance scores for visual design principles. * UX principle plans: Delivers evidence-labeled UX guidance with design questions, cautions, and references. * UI state plans: Returns required/recommended UI states for surfaces (e.g., data-table, form, checkout) with triggers, accessibility, and motion guidance. * Compose design tokens: Generates role-based tokens (color, typography, spacing, etc.) in JSON, CSS variables, Tailwind, or TypeScript, with light/dark modes and WCAG contrast warnings. * Design audit plans: Provides localized, surface-aware audit checks with severity, required evidence, and remediation suggestions. * Catalog browsing: Access styles, motion profiles, components, principles, UI-state recipes, and product archetypes via MCP resources. * Ready-made prompts: Built-in MCP prompts for common design workflows (e.g., designing products, screens, or audits). * Localized output: All results, reason codes, and guidance available in English, Korean, or Japanese. * Deterministic & private: No API keys, network calls, or filesystem access; same inputs always yield the same outputs.

How do I use web-stylebook-mcp?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@web-stylebook-mcp Recommend a design direction for a finance dashboard." 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.

web-stylebook-mcp

by seungdori

Overview Schema Related Servers Score Discussions

TypeScript

Local

web-stylebook-mcp

Design intelligence for AI coding agents. Stop shipping the same hero-plus-three-cards. Your agent gets scored design contracts — directions, interface-design plans, UX-principle plans, UI-state plans, tokens, evidence-backed audit plans — then writes and verifies the code from evidence.

npm version downloads license node MCP

English · 한국어

Coding agents default to the same generic UI because they can't decide what it should look like — so they fall back to hero + 3 cards + a gradient. web-stylebook-mcp is a Model Context Protocol server that hands the agent design contracts — scored visual directions, placement-aware interface-design plans, evidence-labeled UX-principle plans, UI-state plans, and design tokens — drawn from the same curated catalog as webstylebook.com. It returns evidence, not code. Your agent still writes the code — now it knows what to build and what to verify.

No API key. No model call. No network. No project filesystem access. Deterministic, read-only, fully local.

Without it / with it

	Without `web-stylebook-mcp`	With `web-stylebook-mcp`
Direction	Guesses one look, commits to it	Scored candidates + reason codes + what it rejected and why
Craft	Principle names dropped into a doc, nothing verified	Placement guidance + an observable check per principle, cautions attached
UX evidence	"Hick's Law says…" as a conversation-ender	Evidence-labeled prompts (`strong` / `contextual` / `contested`) you can't restate as law
UI states	Happy path only; empty / error / loading bolted on later	Required / recommended / domain states up front, per surface
Tokens	Hand-picked hexes, contrast rarely checked	Role-based tokens with WCAG contrast warnings
Audit	"Looks good" from a summary	Surface-aware checks with stable ids, severity, required evidence, and explicit unverified states
Result	Generic AI UI	A defensible design contract the agent builds from

Related MCP server: mcpsystem.design MCP Server

Watch it decide

"High-density monitoring dashboard for SREs, watched all day on call. Calm, technical. Avoid cyberpunk."

// → recommend_design_direction  (input)
{
  "productDescription": "High-density monitoring dashboard for SREs, watched all day on call",
  "productType": "operational-saas",
  "tone": ["calm", "technical"],
  "density": "high",
  "usageFrequency": "daily",
  "avoid": ["cyberpunk"]
}

// ← result
{
  "confidence": "high",
  "candidates": [                      // all tied at 0.91 — ordering is NOT meaningful
    { "styleId": "notion-style",   "score": 0.91 },
    { "styleId": "platform-core",  "score": 0.91 },
    { "styleId": "quiet-utility",  "score": 0.91 },
    { "styleId": "runtime-signal", "score": 0.91 },
    { "styleId": "console-launch", "score": 0.91 }
  ],
  "rejected": [
    { "styleId": "aurora-gradient",  "reasonCodes": ["PRODUCT_NOT_IDEAL", "DAILY_USE_OVERSTIMULATION"] },
    { "styleId": "claymorphism",     "reasonCodes": ["PRODUCT_NOT_IDEAL"] },
    { "styleId": "cyberpunk-glitch", "reasonCodes": ["EXPLICITLY_AVOIDED", "DAILY_USE_OVERSTIMULATION"] }
  ],
  "pairings": [
    {
      "styleId": "macos-liquid-glass",
      "pairWith": "notion-style",
      "role": ["forms", "navigation", "repetitive surfaces"]
    }
  ],
  "guidance": "Treat candidates as scored evidence; choose using product context. candidates[0] is the strongest match, not a mandate. 5 candidates are tied at the top score — the ordering among them is not meaningful; pick using their \"differentiators\" and your product context."
}

Notice what it doesn't do: it doesn't pretend there's one winner. Five directions tie at 0.91, rejected styles come with reason codes, and pairings are suggestions rather than a mandate. That honesty is the point — the server provides evidence, the agent decides.

Then turn the chosen direction into real tokens:

// → compose_design_tokens(style: "notion-style", format: "css-variables", theme: "light")
// 0 WCAG contrast warnings
:root {
  --color-canvas: #ffffff;
  --color-text:   #37352f;
  --color-accent: #2383e2;
  --color-border: #d3d3d1;
  /* … role-based color, type, spacing, radius, motion, density */
}

One request in — and the agent chose a direction, saw what was rejected and why, and got tokens that pass WCAG, without generating a line of code.

What an agent builds with it

A different brief — "a marketing landing page for Throughline, a B2B SaaS that turns scattered customer feedback (support tickets, sales calls, app reviews, Slack) into one prioritized roadmap." No layout, no hero, no styling was specified. Following the companion skill, the agent composed the opening from the product's core idea instead of reaching for a stock hero: the right half is a bespoke diagram of the product's actual mechanic — feedback sources converging into an auto-ranked roadmap — not a decorative card you could paste onto any other site.

How it works

flowchart LR
    A[AI coding agent] -->|product, tone,<br/>density, usage| B(web-stylebook-mcp)
    B --> C{Bundled catalog<br/>read-only · offline}
    C --> D[recommend_design_direction]
    C --> E[compare_design_directions]
    C --> F[get_design_principle_plan]
    C --> G[get_ux_principle_plan]
    C --> H[get_ui_state_plan]
    C --> I[compose_design_tokens]
    C --> J[get_design_audit_plan]
    C --> K[search_design_references]
    C --> L[get_design_reference]
    C --> M[validate_design_audit_result]
    D & E & F & G & H & I & J & K & L -->|design contracts<br/>observations · scores · reasons<br/>placement · evidence · tokens| A
    A -->|target matrix · evidence refs<br/>one verdict per check/target| M
    M -->|coverage · normalized verdicts<br/>plan/evidence/result hashes| A
    A -->|writes code<br/>from evidence| Z[Your UI]

The agent describes the product; the server scores its curated catalog and returns structured evidence. After inspection, the validator checks the result contract without opening the referenced artifacts or judging visual quality. No code is generated and nothing leaves your machine.

Install

Requires Node ≥ 20.

Use the Codex CLI:

codex mcp add web-stylebook -- npx -y web-stylebook-mcp@latest

Or add it to ~/.codex/config.toml. You can also use a project-scoped .codex/config.toml in a trusted repository:

[mcp_servers.web-stylebook]
command = "npx"
args = ["-y", "web-stylebook-mcp@latest"]

Restart Codex or open a new session after editing config. In the Codex TUI, run /mcp to confirm the server is active.

claude mcp add web-stylebook -- npx -y web-stylebook-mcp@latest

Add to your MCP config:

{
  "mcpServers": {
    "web-stylebook": {
      "command": "npx",
      "args": ["-y", "web-stylebook-mcp@latest"]
    }
  }
}

Add the same block to your claude_desktop_config.json, then restart:

macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
Windows: %APPDATA%\Claude\claude_desktop_config.json

{
  "mcpServers": {
    "web-stylebook": {
      "command": "npx",
      "args": ["-y", "web-stylebook-mcp@latest"]
    }
  }
}

Tools

Tool	What you get	The honest part
`recommend_design_direction`	Scored style candidates with reason codes, rejected styles with why, secondary pairings, confidence	The model makes the final pick — this is the evidence provider
`compare_design_directions`	2–4 directions compared across product-fit, repeated-use, density, trust, distinctiveness, accessibility-risk, motion, maintenance	No single winner is declared
`search_design_references`	Bounded search across real-world references by text, category, and tags, with concise localized observations	Returns attributed research summaries, not copied screenshots or brand assets
`get_design_reference`	One complete localized reference with palette/layout/interaction/motion observations, normalized tokens, source revision, attribution, and rights notice	Original-site copy, typefaces, screenshots, and visual identity remain with their owners
`get_design_principle_plan`	A focused placement, application, and verification plan selected by visual concerns, surface, phase, or principle ids — with source references where available	Craft prompts are testable guidance, not empirical laws or a fixed recipe
`get_ux_principle_plan`	A focused apply-and-verify plan selected by outcomes, surface, phase, or principle ids — with questions, cautions, confidence, and references	Principles are contextual prompts, not universal laws or a substitute for research
`get_ui_state_plan`	Required / recommended / domain UI states for a surface (data-table, form, checkout, chat, developer-console) — triggers, must-show, must-not, a11y, motion	Covers the states agents forget: empty, error, loading, edge
`compose_design_tokens`	Role-based tokens (color, type, spacing, radius, motion, density) as `json` / `css-variables` / `tailwind` / `typescript`, light / dark / both	Emits WCAG contrast warnings instead of hiding them
`get_design_audit_plan`	Localized, surface-aware checks with stable ids, severity, applicability, required evidence, remediation, user-facing content checks, selected principle checks, and UI-state coverage	The tool plans the audit but never pretends it inspected your project; missing evidence is `NOT_VERIFIED`, not `PASS`
`validate_design_audit_result`	Contract validation for the plan query, target matrix, durable evidence references, and one verdict per check/target, with normalized verdicts and stable hashes	It verifies coverage and evidence consistency, not visual quality; `valid: true` is never an overall design pass

Catalog: 520 real-world design references · 48 styles · 25 interface design principles · 23 UX principles · 51 structured audit checks · 20 components · 5 surfaces · 57 UI-state recipes · 29 motion profiles · 14 product archetypes.

The reference library is an adapted, high-completeness subset of OpenDesign, whose structured specifications are licensed under CC BY 4.0. Web Stylebook excludes upstream screenshots and brand assets. Original sites, brands, copy, typefaces, and visual identities remain the property of their respective owners; inspect each detail's attribution and rights notice before use.

Localized output

Every tool takes an optional locale. Reason codes, guidance, and labels come back in the requested language:

"en" | "ko" | "ja"     // English · 한국어 · 日本語

Resources

Browse the catalog directly over MCP resources:

webstylebook://manifest
webstylebook://styles · /styles/{id}
webstylebook://motion · /motion/{id}
webstylebook://components · /components/{id}
webstylebook://principles · /principles/{id}
webstylebook://design-principles · /design-principles/{id}
webstylebook://states/surfaces · /states/{surface} · /states/{surface}/{state}
webstylebook://products · /products/{id}
webstylebook://references · /references/{id}
webstylebook://policies/anti-patterns · /policies/verification · /policies/audit-checks

Prompts

Ready-made MCP prompts for common workflows:

design-product · design-screen · complete-ui-states · redesign-with-style · audit-design-direction · audit-design-principles · audit-ux-principles

When audit-design-direction is invoked without an explicit scope, it asks two short questions before inspection: audit coverage (visual / visual + copy and information structure / full experience) and change depth (findings / proposals / implement and verify). File edits, commits, releases, and deployment are never inferred from an audit request.

Content coverage checks more than jargon: it tests whether material claims, conclusions, and recommendations match their support and expressed certainty, whether prominent copy conveys concrete context-specific information, and whether its visual emphasis matches information value, task relevance, and support. Cards, statistics, and Sitemap links are still judged by their actual user-task value rather than banned as types.

Audit result contract

get_design_audit_plan now returns an identity with the catalog version/hash and a deterministic planHash. After inspecting the actual implementation, submit the same plan query plus:

one target per inspected route or screen, state, viewport, theme, locale, and role;
evidence with a durable artifact reference, content hash, or exact route/selector/file/region;
a before/input/after/recovery phase for interaction evidence; and
one result for every planned check/target pair.

validate_design_audit_result regenerates the plan and rejects stale plan hashes, missing or duplicate result slots, broken evidence references, cross-target evidence, invalid regions, unsupported NOT_APPLICABLE, and PASS that lacks required evidence or contradicts failed evidence. Missing result slots are materialized as NOT_VERIFIED, never hidden. The result carries content-addressed plan, evidence-bundle, and normalized-result hashes for comparable rechecks. The tool never opens the artifact references and never turns contract validity into a design-quality score.

The repository includes a reproducible contract-quality benchmark:

npm run eval:audit-contract

Across 14 human-labeled normal and adversarial cases, legacy pass-through verdicts score 4/14 (28.57%) with 9 false PASS results. The validator scores 14/14 with 0 false PASS results and classifies every contract-valid/invalid case correctly. The corpus covers missing, narrative-only, unknown, cross-target, indeterminate, phase-less, blocker/major/minor failure, honest NOT_VERIFIED, and valid/invalid NOT_APPLICABLE cases. This demonstrates result-contract correctness; it does not claim that subjective visual judgment itself is 100% accurate.

CLI

web-stylebook-mcp                 # run the server over stdio (default)
web-stylebook-mcp --version
web-stylebook-mcp --catalog-info
web-stylebook-mcp --validate-catalog

Companion skill

A companion skill ships in skill/ so your agent reaches for these tools at the right moment — and uses the results well (compose, don't recolor; offer multiple candidates; earn trust, don't fake it; land on reusable components):

Codex

Copy or symlink skill/web-stylebook-design/ into a Codex skill location such as .agents/skills/web-stylebook-design/ in your repo, or ~/.agents/skills/web-stylebook-design/ for your user profile.
If you do not want to install the skill, copy skill/AGENTS.md into your project's AGENTS.md.

Claude Code and other agents

Point your agent's skills directory at skill/web-stylebook-design/, or
Copy skill/CLAUDE.md into your project's CLAUDE.md or equivalent rules file.

Privacy & security

Property
API key	None
Model calls	None
Network access	None — works fully offline
Project filesystem access	None — the server only reads its bundled catalog snapshot
Behavior	Deterministic, read-only

The server reads from a catalog snapshot bundled in the package. Nothing is sent anywhere; the same inputs always yield the same contracts.

Catalog source sync

The canonical catalog is authored in the web-stylebook repository. After generating its local MCP handoff snapshot, verify byte-for-byte parity before releasing this package:

npm run catalog:check-canonical -- /absolute/path/to/web-stylebook/packages/mcp/generated

Without an argument, the command uses WEB_STYLEBOOK_CANONICAL_CATALOG_DIR or the local sibling path ../showcase/packages/mcp/generated. The regular test suite verifies the bundled artifact's internal hash, enums, counts, and runtime contract; this command is the explicit cross-repository source check.

Compatibility

Node: ≥ 20
Transport: stdio (Model Context Protocol)
Clients: Codex CLI / IDE extension, Claude Code, Claude Desktop, Cursor, Windsurf, and any MCP-compatible client

License

MIT — covers the code and the bundled catalog snapshot (free for commercial use).

The webstylebook.com website is licensed CC BY-NC. The same owner grants an MIT license for the catalog snapshot bundled in this package.
UX-principle entries are independently written application and verification guidance. They attribute and link to Laws of UX (CC BY-NC-ND 4.0) and supporting references; Laws of UX prose, illustrations, and page layouts are not bundled.
Interface-design-principle entries form an independently authored, task-oriented review system for contemporary interfaces. They cover semantic structure, responsive reflow, localization, tokens and themes, multiple input modes, complete state models, recovery, and motion preferences.

Available Tools

6 tools

compare_design_directionsCompare design directionsA

Read-onlyIdempotent

Compare 2-4 directions across product fit, repeated-use suitability, density, trust, distinctiveness, accessibility risk, motion and maintenance. Returns each direction's favorable conditions and likely failure mode — never a single winner.

ParametersJSON Schema

Name	Required	Description	Default
`locale`	No
`product`	No
`directions`	Yes

TDQS

A3.5/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations indicate read-only, idempotent, and non-destructive behavior. The description adds valuable context about output (favorable conditions and failure modes) and the criteria evaluated, which goes beyond the annotations. No contradictions.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single concise sentence that front-loads the purpose and includes key behavioral details. Every word earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the complexity (3 parameters, nested objects, no output schema), the description is insufficient. It lacks explanations for the 'directions' structure, 'product' fields, and required parameters, making it hard for an agent to use correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, and the description provides no explanation of the parameters (directions, locale, product object). For a tool with nested objects and multiple fields, this is a major gap.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool compares 2-4 design directions across specific criteria (product fit, repeated-use suitability, etc.) and specifies it returns favorable conditions and failure modes per direction, never a single winner. This effectively distinguishes it from the sibling tool 'recommend_design_direction' which likely picks a winner.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage for comparison across multiple directions but does not explicitly state when to use this tool versus alternatives like 'recommend_design_direction'. It contrasts 'never a single winner' but lacks explicit when-to-use or when-not-to guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

compose_design_tokensCompose design tokensA

Read-onlyIdempotent

Compile a starting set of role-based design tokens (color, typography, spacing, radius, motion, density) for a style in json / css-variables / tailwind / typescript, with light/dark/both modes, accent override, and WCAG contrast warnings.

ParametersJSON Schema

Name	Required	Description	Default
`format`	Yes
`locale`	No
`density`	No
`colorMode`	No
`accentOverride`	No
`primaryStyleId`	Yes
`secondaryStyleId`	No

TDQS

A3.9/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint. The description adds behavioral details beyond that: it compiles tokens, supports light/dark/both modes, accent override, and WCAG contrast warnings. No contradictions with annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single sentence that front-loads the action and lists key options. It is reasonably concise and avoids redundancy, though it could be broken into multiple sentences for better readability.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given 7 parameters, no output schema, and no param descriptions, the description provides a decent high-level overview but lacks parameter-level details needed for correct invocation. It covers the tool's purpose and key behaviors but is incomplete for parameter understanding.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must explain parameters. It mentions high-level token categories (color, typography, etc.) but does not map them to specific parameters like primaryStyleId, secondaryStyleId, locale, or density. Details about enums and required fields are missing, leaving the agent without enough context to correctly set parameters.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb ('Compose') and resource ('design tokens') and lists concrete categories (color, typography, etc.) and output formats. It clearly distinguishes from sibling tools like recommend_design_direction or compare_design_directions, which cover different design tasks.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies the tool is for generating tokens for a style, and sibling tools cover separate design decisions (direction, principles). While no explicit 'when to use' or exclusions are stated, the context makes it clear this is for token compilation rather than other design activities.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_design_principle_planPlan relevant design principlesA

Read-onlyIdempotent

Select a small set of practical visual-design principles for intent and iteration, semantic hierarchy, adaptive layout and density, typography and localization, tokens and themes, accessible interaction, and complete states and recovery. Filter by design concerns, surface, phase, or explicit ids. Returns placement guidance, application steps, verification checks, cautions, related principles, and deterministic relevance scores.

ParametersJSON Schema

Name	Required	Description	Default
`limit`	No
`phase`	No
`locale`	No
`surface`	No
`concerns`	No
`principleIds`	No

TDQS

A3.9/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations indicate read-only, idempotent, non-destructive behavior, which is consistent with 'Select... Returns...' in the description. The description adds transparency by listing specific output elements (e.g., placement guidance, verification checks, relevance scores) and filtering capabilities, providing valuable context beyond annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two efficient sentences with no redundant language. The first sentence establishes the tool's purpose and scope, and the second covers filtering and output. Every word adds value.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the complexity (6 parameters, no output schema), the description covers core functionality but omits details on limit and locale parameters, and does not specify behavior for edge cases like no results. Annotations provide safety context, but the description could be more thorough.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, so the description must compensate. It explains filtering by concerns, surface, phase, or ids (4 of 6 parameters), but fails to mention limit and locale parameters. This partial coverage adds some meaning but leaves gaps.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool selects a small set of practical visual-design principles and details the output (placement guidance, application steps, etc.). It distinguishes from sibling tools like recommend_design_direction and get_ux_principle_plan by specifying the domain (visual-design) and output format.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage through filtering options (concerns, surface, phase, ids) but does not explicitly state when to use this tool over alternatives like get_ux_principle_plan or compose_design_tokens. No guidance on prerequisites or exclusions is provided.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_ui_state_planPlan UI states for a surfaceA

Read-onlyIdempotent

For a surface (data-table, form, checkout, chat, developer-console), return required / recommended / domain-specific states with triggers, must-show, must-not, accessibility and motion guidance, plus an implementation order. Covers the non-happy-path.

ParametersJSON Schema

Name	Required	Description
`locale`	No
`styleId`	No	optional catalog style id (see webstylebook://styles) to tailor state guidance
`surfaceId`	Yes	surface id — one of: data-table \| form \| checkout \| chat \| developer-console
`criticalOnly`	No
`domainSignals`	No
`productContext`	No
`includeCategories`	No

TDQS

A3.6/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint and idempotentHint, so the tool is safe and non-destructive. The description adds behavioral details about the output (states, triggers, must-show/must-not, accessibility, motion, implementation order) and that it covers non-happy-path, providing sufficient context beyond annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single concise sentence that front-loads the purpose and key details (surface types, output components, non-happy-path). It is efficient and easy to parse, though could be slightly more structured.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With 7 parameters, low schema coverage (29%), and no output schema, the description is incomplete. It does not cover parameter purposes or return value structure, which is needed for a planning tool with many parameters.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is only 29%, with only surfaceId and styleId having descriptions. The description aligns with surfaceId by listing surfaces, but does not explain other parameters like domainSignals, productContext, criticalOnly, or includeCategories, leaving significant gaps in parameter understanding.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool plans UI states for a specific set of surfaces, listing what it returns (required/recommended/domain-specific states, triggers, guidance, implementation order) and explicitly mentions covering non-happy-path, distinguishing it from sibling tools that focus on design directions or principles.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage when planning UI states for surfaces like data-table, form, etc., and emphasizes non-happy-path, but does not provide explicit guidance on when to use this tool versus sibling tools like recommend_design_direction or get_design_principle_plan.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_ux_principle_planPlan relevant UX principlesA

Read-onlyIdempotent

Select a small, evidence-labeled set of UX principles for a target outcome, surface, design phase, or explicit principle ids. Returns design questions, application steps, verification checks, cautions, references, and relevance scores. Treat the result as decision prompts rather than universal laws.

ParametersJSON Schema

Name	Required	Description	Default
`limit`	No
`phase`	No
`locale`	No
`surface`	No
`outcomes`	No
`principleIds`	No

TDQS

A4/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations declare readOnlyHint, idempotentHint, and destructiveHint, which the description does not contradict. The description adds behavioral context by noting the output should be treated as decision prompts and lists specific return components.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences: first sentence states purpose and inputs, second sentence states outputs and a caveat. No redundant information; every sentence adds value.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no output schema, the description adequately explains return values (design questions, steps, etc.) and adds a usage caveat. It could mention default behavior for 'limit' or 'locale', but overall is complete for agent decision-making.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must explain parameters. It mentions 'outcome, surface, phase, principle ids' which map to four of six parameters, but omits 'limit' and 'locale'. Without full coverage, the description only partially compensates.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool selects a set of UX principles based on specific criteria (outcome, surface, phase, IDs) and lists the return elements. It distinguishes from siblings like 'get_design_principle_plan' by focusing on UX principles and including evidence labels.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage through input criteria but does not explicitly state when to use or avoid this tool versus alternatives. Sibling tools like 'recommend_design_direction' are not contrasted, leaving the agent to infer.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

recommend_design_directionRecommend a design directionA

Read-onlyIdempotent

Given product context, return scored style candidates with reason codes, rejected styles with reasons, secondary pairings, assumptions and confidence. Evidence-provider: the host model makes the final pick. Call before writing UI. The "tone" field (named "tone", not "tones") is an ARRAY of zero or more of: calm, technical, trustworthy, premium, editorial, playful, bold, experimental. Each candidate.score already includes soft penalties (density/motion/tone fit) that are not itemized in scoreBreakdown.

ParametersJSON Schema

Name	Required	Description	Default
`tone`	No
`avoid`	No
`locale`	No
`density`	No
`audience`	No
`constraints`	No
`productType`	No
`primaryTasks`	No
`candidateLimit`	No
`usageFrequency`	No
`trustSensitivity`	No
`productDescription`	Yes

TDQS

A4/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. Description adds context that the tool is an evidence-provider (host model picks), clarifies that scores include soft penalties, and corrects potential naming confusion for 'tone'. No contradictions.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Three sentences with no fluff: first sentence covers output, second gives usage context, third clarifies tone and score composition. Information is front-loaded and every sentence earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Covers main output structure and usage timing, but fails to document most input parameters. With 12 parameters and 0% schema coverage, more detail on param effects is needed for full agent comprehension.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Only the 'tone' parameter is explained (allowed values, field name, array type). Schema coverage is 0%, so description must compensate, but other 11 parameters lack any explanatory text. The description adds marginal value beyond enum definitions in schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Description specifies 'return scored style candidates' with reasons and rejected styles, clearly distinguishing from sibling 'compare_design_directions' by stating the host model makes the final pick and that this tool should be called before writing UI.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Includes explicit directive 'Call before writing UI' and indicates the tool is for evidence provision, not decision-making. However, does not explicitly state when not to use or compare with siblings like 'compare_design_directions'.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

6 tool updatesv0.3.0Jul 29, 2026
- First observedcompare_design_directions
- First observedcompose_design_tokens
- First observedget_design_principle_plan
- First observedget_ui_state_plan
- First observedget_ux_principle_plan
- First observedrecommend_design_direction

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4/5.0

Disambiguation5/5

Each tool targets a distinct aspect of design guidance: direction recommendation, direction comparison, design principles, UX principles, UI state planning, and token composition. No two tools overlap in purpose.

Naming Consistency5/5

All tool names follow a verb_noun pattern (recommend, compare, get, compose) with consistent use of snake_case and predictable object naming (e.g., get_design_principle_plan, get_ux_principle_plan).

Tool Count5/5

6 tools is well-scoped for a design guidance server. Each tool covers a necessary function without redundancy or excessive specialization.

Completeness4/5

The set covers core design activities: direction selection, comparison, principles (design/UX), state planning, and token generation. A minor gap is the lack of a tool to apply or test tokens on actual components, but the scope is reasonable.

Maintenance

ActivityMaintained

ResponsivenessSyncing

Resources

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Tseha AFeatured
io.tseha
Serves your design system and coding standards to coding agents, so they stop guessing.
Developer Tools Documentation Access
93
Curio — design style libraryOAuth
com.designbycurio
A design-style library for AI agents: search real styles, fetch a ready-to-apply design spec.
Design Tools AI & Machine Learning
2
design-system
app.zaklad
Build and manage your design system with AI: tokens, themes, components, icons, Figma and code.
Design Tools Developer Tools
2
Supernova
io.supernova
Access and maintain design system docs, tokens, components, skills, and contexts across any project.
Design Tools Documentation Access Developer Tools
1

Related MCP Servers

Visa Design System MCP Server
MarySuneela
F
license
B
quality
D
maintenance
Provides AI tools with access to Visa's Product Design System resources, including design tokens, component specifications, and usage guidelines.
Updated a year ago (2025-07-24 01:59 UTC)
11
-
mcpsystem.design MCP Server
Developer Tools Software Architecture Content Management Systems
heyadam
A
license
Not graded
quality
D
maintenance
Provides AI assistants with access to a production-ready design system including Tailwind CSS component patterns, style guides (colors, typography, spacing), and Web Components specifications for consistent UI development.
Updated 3 months ago (2026-06-04 11:52 UTC)
19
MIT
Primitiv
Design Tools Developer Tools Knowledge & Memory
AI-by-design
A
license
A
quality
A
maintenance
Design contract layer for AI agents. Scans Figma, code, Storybook, and token files, reconciles conflicts, and serves a single machine-readable source of truth so every agent gets the same authoritative design rules before it builds. Local-first.
Updated 2 days ago (2026-09-04 13:12 UTC)
6
1,205
19
Apache 2.0
Material 3 MCP Server
Design Tools Documentation Access
weppa-cloud
A
license
A
quality
C
maintenance
Provides AI agents with tools to access Material 3 design components, design tokens, icons, and accessibility guidelines across multiple frameworks.
Updated a year ago (2025-09-30 01:52 UTC)
8
37
6
MIT

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/seungdori/web-stylebook-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server