design-system-mcp
Related Servers
Alternatives to design-system-mcp
No user-submitted related servers found.
Related Servers
- AlicenseNot gradedqualityBmaintenanceEnables coding agents to query a workspace's design system before writing UI and validate generated code against the same system afterward, using configurable token and component sources.13 npm1MIT
- AlicenseAqualityBmaintenanceA design harness for AI coding agents. Better Design gives an agent design systems, UI and UX principles, icons and UI review: it finds or creates a design system that fits the product and installs its components, explains how sign-up, forms and onboarding should work, and reviews finished screens for readability, accessibility and unclear copy.48538MIT
- AlicenseNot gradedqualityBmaintenanceEnables coding agents to read a React app's design-system context, scan for UI drift in buttons, cards, colors, and spacing, retrieve findings with file:line evidence and expected tokens, and verify fixes by rescanning affected routes.03MIT
- AlicenseNot gradedqualityCmaintenanceEnables AI agents to query a design system's components, tokens, icons, patterns, and usage or accessibility guidelines through standardized MCP tools, with pluggable adapters for different data sources.MIT
- AlicenseAqualityCmaintenanceMCP server for the Lando Labs Design System, enabling AI agents to introspect and generate code for React components, hooks, icons, design tokens, and theme presets via 15 tools.157 npm1Apache 2.0
- AlicenseAqualityBmaintenanceIt lets AI coding agents look up design tokens, component specifications, and prohibition rules on demand, then validate generated HTML or JSX with the same lint logic used by CI and editor hooks so violations are caught and corrected immediately. It also exposes the design constitution and rule sets as resources for reference during generation.6103 npm202MIT
TDQS
Scored across 5 tools
Each tool occupies a clearly distinct niche: list_components (exhaustive catalog), get_component (single contract), search_components (intent-based discovery), get_tokens (token values), and check_ui (lint/validation). The list vs. get vs. search trio mirrors a well-understood pattern, and the descriptions explicitly state when to use each, so misselection is unlikely.
All names follow a predictable snake_case verb_noun convention (list_components, get_component, search_components, get_tokens, check_ui). Verbs are well-chosen and resource nouns are used consistently across the set.
Five tightly scoped tools cleanly cover the design-system consumption lifecycle: discover, inspect, search, read tokens, and validate. Nothing is redundant and nothing feels missing from a count standpoint.
The surface covers component discovery, contracts, tokens, and linting very well, which are the core consumption workflows. There is a minor gap around overall setup/theming guidance (e.g. provider wiring, global conventions), but agents can work around it via get_tokens and doc examples.