design-system-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
| prompts | {
"listChanged": true
} |
| resources | {
"listChanged": true
} |
| completions | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| list_componentsA | List every component in the project design system with a one-line description, the native element it renders, its variant values, its parts and its import. Call this before writing UI in this project. At a monorepo root, pass |
| get_componentA | Get the full contract of one component: import, props with types and defaults, cva variants and the classes each applies, parts (sub-components), design tokens it uses, usage guidelines and examples from its docs. Call it before using a component. Accepts "Button", "CardHeader" or "Card.Header". At a monorepo root, pass |
| search_componentsA | Find components by what you want to build, e.g. "confirm a destructive action", "status label", "text field with validation". Ranks names, descriptions, docs, props and variant values with BM25 (local, no API key). Use it when you do not know which component fits. |
| get_tokensA | List design tokens with resolved values, dark-mode values and how to use each (Tailwind class or CSS variable). Filter by category (color, spacing, radius, typography, shadow, other) or a substring. Use these instead of hex codes, px values or Tailwind default palette classes. |
| check_uiA | Lint TSX/JSX against the design system. Reports hardcoded colors, spacing and radius (with the nearest token), native elements that have a design-system component, unknown components, props and variant values, and icon-only buttons without an accessible name. Each diagnostic has line/column, a rule id, a message and a suggested fix. Run it on every snippet or file you write and fix all errors. Pass |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
| build-with-design-system | Build a piece of UI using only design-system components and tokens, then verify it with check_ui. |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
| tokens | Every design token with resolved values, modes and usages, as JSON. |
| Badge | A small status label: counts, states ("Active", "Overdue") or categories. Not interactive by default; pass `asChild` to render a link. |
| Button | Triggers an action or event, such as submitting a form, opening a dialog or deleting a record. Use `variant="destructive"` for irreversible actions and `variant="link"` for navigation that should look like a button. |
| Card | A bordered surface that groups related content and actions. |
| CardHeader | Top section of a card. Holds `CardTitle`, `CardDescription` and an optional `CardAction`. |
| CardFooter | Bottom section of the card, usually for actions. |
| CardTitle | The card heading. |
| CardAction | An action pinned to the top-right corner of the header, e.g. a menu button. |
| CardDescription | Secondary text under the title. |
| CardContent | The main body of the card. |
| Dialog | A modal window that interrupts the user to confirm a decision or collect input. Use it to confirm destructive actions before they happen. |
| DialogClose | Closes the dialog. Use `asChild` to wrap a `Button`. |
| DialogContent | The dialog panel. Renders the overlay and a close button for you. |
| DialogDescription | Explains what will happen. Announced by screen readers when the dialog opens. |
| DialogFooter | Action row at the bottom of the dialog. Put the primary action last. |
| DialogHeader | Holds `DialogTitle` and `DialogDescription`. |
| DialogOverlay | Props, variants, parts, tokens, guidelines and examples for one component. |
| DialogPortal | Props, variants, parts, tokens, guidelines and examples for one component. |
| DialogTitle | Required: the accessible name of the dialog. |
| DialogTrigger | The element that opens the dialog. Use `asChild` to wrap a `Button`. |
| Input | A single-line text field. Always pair it with a visible `<label htmlFor>` or an `aria-label`; set `aria-invalid` to show the error state. |
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.