A UI design MCP with real references

A UI design MCP server lets a coding agent ask for design evidence while it works: real screens, user journeys and design systems. MCP (Model Context Protocol) is the standard way agents like Claude Code, Cursor and Codex call outside tools.

It's different from a design skill. A skill is a set of instructions ("check the empty state", "avoid decorative gradients"). An MCP server is a source of facts the agent doesn't have. They work best together, which is why UXKIN's setup installs both.

Example task used in this guide: redesign a subscription cancellation flow, using two real apps' flows to decide the order of steps.

When a design MCP helps

Not every task needs one. If you already have a screenshot of what you want, or you're fixing a bug in an existing screen, your agent can work from that. A reference server earns its place when a decision depends on how real products do it and nobody on the task knows yet:

• How many steps a flow like onboarding or cancellation usually takes.
• Where products put a secondary action, like "pause instead".
• What a dense settings or dashboard screen looks like when it works.
• Which colors and type pairings a style of product tends to use.

Without evidence, agents fall back to the same defaults every time: a centered hero, three identical cards, a purple gradient. The comparison above shows the difference on one screen.

What UXKIN's two tools do

find_ui_references

Searches 300+ mobile apps (their screens and user journeys) and 1,200+ websites. Ask it in plain words, the way you'd describe the screen to a colleague. A search for "canceling subscription" returns journeys like this, each with a preview image and a link to every screen:

{
  "type": "journey",
  "title": "Canceling subscription",
  "subtitle": "DailyArt",
  "description": "5 screens",
  "image": "https://media.uxkin.com/mobile/…webp",
  "href": "https://uxkin.com/apps/…?journey=…"
}

find_ui_materials

Searches UXKIN's web design systems for concrete materials: named colors with the role each one plays, typography, components and, with full access, the complete DESIGN.md. For example, a "dark fintech" search returns a palette where every color explains its job ("page canvas", "elevated card surfaces", "link accents, never the primary button"). Roles like that are what stop an agent from sprinkling one accent color everywhere.

Both tools are read-only: they return information and never change anything in your project or account.

Connect in two minutes

1. Create a UXKIN account and open the Agent SDK tab on the homepage.
2. Click Copy setup prompt and paste it into your agent. It installs the no-ui-slop skill and connects https://uxkin.com/mcp with your token, using your client's own MCP settings.
3. Ask the agent to confirm both tools are available. It shouldn't run a test search; the first real UI task is the test.

Keep the token in local agent settings or an environment variable, never in a repository, a link or a screenshot. If it leaks, use Reset token and the old one stops working.

From references to a decision

Back to the cancellation flow. The useful question isn't "show me cancellation screens". It's "how do real apps order these steps, and where do they offer an alternative?" With UXKIN connected, the agent:

1. Calls find_ui_references with "canceling subscription" and picks two journeys, say a 5-screen and a 6-screen flow.
2. Compares them on the questions that matter: number of steps, where an alternative like pausing appears, how the final screen confirms what you keep.
3. Writes down which decisions it's adopting and why, in one or two lines each, before touching code.
4. Builds the flow with your components, then renders it and checks the loading, error and success states on a small screen.

Ask your agent to name the references it used and the decision each one supported. If its description doesn't match what the screens show, stop and correct it before it builds on a misreading.

What it won't do

• It won't design the whole interface for you. It answers specific questions; your agent still has to make the decisions.
• It doesn't replace your design system. Your tokens, components and requirements always win over a reference.
• It can't guarantee the agent reads an image correctly, which is why asking it to explain its evidence matters.
• Some searches come back thin. Rephrase with the product type or the flow's name ("onboarding", "settings") and try again.

A prompt you can use

Adapt this to your own product. It asks one clear question of the references and requires the agent to explain its evidence:

Redesign the subscription cancellation flow in our mobile app. Keep our existing components and tokens.

If UXKIN is connected, use find_ui_references for "canceling subscription" and pick the two most relevant journeys. For each, note: how many steps it takes, where it offers an alternative (pause, downgrade), and how it confirms what the user keeps or loses. Say which of those decisions you're adopting and why.

Implement the flow with loading, error and success states, then render it and check it on a small screen.

Questions