how to give Claude Code real design context with MCP

Claude Code writes great code and mediocre design. Not for lack of taste, but for lack of context. Ask it to build a landing page and it reaches for the same defaults every model ships with: a centered hero, a violet-to-blue gradient, three feature cards, rounded-2xl everything. It has no idea what the primary button on a page you admire actually looks like, because it never saw the page. MCP is how you fix that. This is the concrete setup for wiring a real design teardown into Claude Code, and the workflow for using it without wasting a scan.

why this is an MCP problem, not a prompt problem

You can paste a screenshot and describe what you want. That works until it does not: the model guesses hex values off a compressed image, invents a type scale, and misreads which button is primary. What it is missing is structured data it can trust, delivered inside the tool loop where it is already working.

That is what the Model Context Protocol is for. An MCP server exposes tools your agent can call mid-task, so instead of you narrating a design, the agent fetches it. The common versions pull from Figma files or a local tokens directory. uiscanner does it from any live public URL: paste a link, get back tokens (colors, fonts, type scale, radii, spacing, shadows, motion), a section-by-section structure, and a build prompt Claude can act on.

the install: one line

uiscanner runs as a stdio MCP server over npx, so there is nothing to clone and nothing to host. Add it to Claude Code with:

claude mcp add uiscanner -- npx -y uiscanner-mcp@latest

A note on the syntax, since it trips people up: the -- separates Claude Code's own flags (like --scope or --env) from the command that launches the server. Everything after -- is passed to the server untouched. If you want it available in every project rather than just this one, add a scope flag before the name:

claude mcp add --scope user uiscanner -- npx -y uiscanner-mcp@latest

This is a local stdio server. There is no remote HTTP endpoint to point at, so you will not find a hosted MCP URL to paste in. The first tool call opens a browser to sign in; approve it, then call the tool again and it resumes. The setup page has the same one-liner for Cursor and Codex if you use those too.

the five tools you actually get

Once it is connected, Claude Code sees five tools. Knowing what each one costs and returns is the whole game, because scans are metered and most of your calls should not spend one.

Only ui_teardown costs you anything. The other four are free to call as often as you like, which matters more than it sounds, because the smart workflow leans on them.

the scan-then-build workflow

Here is the loop that gets you a page built against a real design system instead of AI defaults.

1. Check before you scan. Have Claude call whoami to see how many scans you have left, then ui_probe on the URL to confirm it is reachable. Neither spends anything. This catches a dead link or a bot wall before it eats a scan.

2. Scan the reference. Point ui_teardown at a page whose design you want to learn from, and tell it the archetype you are building. The target argument accepts landing, dashboard, marketing, ecommerce, portfolio, mobile, or general, and it shapes the build prompt accordingly. From the CLI the same call looks like this:

npx -y uiscanner-mcp@latest scan stripe.com --target landing

Inside Claude Code you just ask in plain language: "scan stripe.com as a landing page and use its tokens for our pricing page." The teardown comes back as structured data in the tool result, plus an id and a shareable uiscanner.com/t/<id> link. Because uiscanner reads the rendered page and the DOM together, it catches what a CSS scraper misses: the real primary button rather than the first one in the source, whether the hero is centered or split, and which imagery is decorative (with prompts to recreate it as originals, never to copy asset bytes).

3. Build from it. Now Claude has the actual color roles, the type scale, the spacing rhythm, the section order, and a prompt written for a coding agent. Tell it to build your page against those tokens in your own stack. This is the step where the generic defaults disappear, because the model is no longer guessing; it is reading.

the trick most people miss: retarget instead of re-scan

Say you scanned a marketing site and then realize you want its look on a dashboard, where the density, the nav, and the emphasis are all different. The instinct is to scan again. Do not.

retarget_teardown takes the id from a scan you already ran and re-writes the build prompt for a different archetype, without touching the page again. It is far faster and spends no scan. One teardown can feed a landing page, then a dashboard, then a portfolio variant, each with a prompt tuned to that shape, all from a single scan against your quota.

you: retarget teardown t/abc123 to a dashboard
Claude: [calls retarget_teardown, returns a dashboard-shaped build prompt]

The same applies to get_teardown: if you scanned something earlier in a session, or a teammate handed you a uiscanner.com/t/<id> link, Claude can re-fetch the whole thing by id without re-scanning. Treat a scan as a durable asset, not a throwaway call.

a realistic session

Put together, a real Claude Code session looks like this. You ask it to rebuild your pricing page in the spirit of a page you admire. It calls whoami and sees you have scans left, ui_probes the URL, then ui_teardown with target: landing. It reads back the tokens and structure, writes your page using those exact values, and hands you a t/<id> link. Later you decide the same visual language should carry into your settings screen, so it calls retarget_teardown on that id with target: dashboard, having spent exactly one scan the whole time.

That is the difference between an agent that decorates and one that designs from a reference. See the raw material first: browse example teardowns for the output shape, including full breakdowns of the Stripe and Linear design systems, two of the most-copied and least-understood systems on the web.

the one rule to keep it fair

uiscanner is transformative by design. It describes and tokenizes a page; it never copies or re-hosts the original site's asset bytes. What Claude Code receives is a system to build with in your own stack, not a mirror of someone else's site. That is the only version of "learn from this page" that is honest to the sites you learn from, and it is baked into the tool rather than left to your discretion.

quota, briefly

Scans are metered per plan on a rolling 30-day window, and that quota is unified across the web app, the MCP server, and the CLI, so a scan is a scan wherever it runs. Free gives you 5, Indie ($12/mo) 100, and Studio ($39/mo) 400. This is why the workflow above leans on ui_probe, get_teardown, and retarget_teardown: they get a lot of design context out of very few scans. Full numbers are on the pricing page.

get set up

The whole thing is one command. Add the server, sign in on the first call, and let Claude Code fetch design context instead of inventing it:

claude mcp add uiscanner -- npx -y uiscanner-mcp@latest

To see how uiscanner compares to the inspector tools people usually reach for, the uiscanner vs Snable writeup covers where a build prompt beats a color panel. Otherwise, wire it in, point it at a page worth learning from, and let your agent build from a real design system.