MCP for UI components

Why one piece is not a design system

A button with a liquid surface was designed as a button: one size, one context, one moment of attention. It carries no answer for how a data table should look, how dense a form should be or what an empty state says. Stretch its style across an app and every one of those answers gets invented by the model, which is the outcome a design source was meant to prevent.

So the request should name a parent. In an existing app, the parent is your own tokens and components. In a new app, ask the agent to browse for designs that cover several screens or several widgets in one style, lead with one of those, and use the single piece inside it.

Describe the slot

Give the piece's job in your product, not only its type. "A toggle" is a type. "The light and dark switch in the header, 32px tall, next to the avatar" is a slot. Add the real labels and the real number of items: four tabs named as yours are named, five budget categories with their amounts, seven widgets or three.

State what the piece must keep from its design, which is usually its states and its motion, and what it takes from the parent, which is usually colour, type and radius.

Ask for every state

Many of the interface pieces in our library are shown as a loop: the piece plays through its states on a timer so the design can be seen in one viewing. In a product, those states are driven by the user and by data. Ask the agent to wire each state to a real trigger and to list the states it found: resting, hover, pressed, focused, loading, done, error, disabled.

Keyboard and touch belong in the same sentence. A piece that only works under a mouse is a demo.

What a UI component request should contain

• The piece and its slot: what it is, where it goes, its size limits.
• The parent look: your token file, or a fuller design the agent leads with.
• Real content: labels, counts, values.
• Keep and take: states and motion kept; colour, type and radius taken from the parent.
• Triggers: which user action or data change moves it between states.
• Access: keyboard order, visible focus, touch targets of at least 44px, reduced motion.

A prompt to start from

Use the uberdesigner server. I need [the piece, e.g. a one-time code entry card for the sign-in flow]. It goes in [src/screens/Verify.tsx], inside a column 400px wide.

Browse the library and show me up to three pieces that fit: name, link, free or Pro. Wait for my pick.

Rules for building it:
1. This is one piece. Do not restyle anything outside it, and do not treat its style as the look of the app.
2. The look comes from our app: colours, type and radii from [src/styles/tokens.css]. If a value the piece needs has no token, ask before adding one.
3. Keep from the piece: its structure, its states and its motion, with the original durations and easing.
4. The design may play as a timed loop. Replace the loop with real triggers: [typing a digit, pasting six digits, a wrong code from the API, success].
5. States to build and show me in a list: empty, filling, checking, wrong, verified, disabled.
6. Keyboard: digits advance focus, Backspace goes back, paste fills all six. Focus ring 2px. Touch targets at least 44px.

With prefers-reduced-motion, change state without the sweep. Run the app, try each state at 390px wide, and report which files changed.

Needs a coding agent with the uberdesigner MCP server connected and signed in, working in the project the piece belongs to.

Keep reading

• What to ask a connected agentFive habits for requests to an agent with a design MCP: browse first, compare options, name the template, say what is yours, and tell it to keep the design.
• What is a design MCPA plain definition of a design MCP server, what it replaces in a design-to-code workflow, and the things it does not do.

• Claude Code
• Cursor and editors
• Codex and terminal agents
• Chat apps
• Whole websites
• Design morphing