how to stop Cursor from shipping generic AI UI

Ask Cursor to build a pricing page and you already know what comes back: a purple-to-blue gradient, three feature cards in a row, 1px gray borders, Inter headlines, dark mode. It is competent and it is completely generic. The reflex is to blame the model, but the model is doing exactly what it was built to do. The problem is what you handed it, which is almost nothing.

why the default is always the average

A language model predicts the next token from statistical patterns. When you leave a design decision open, the highest-probability answer is the most common one in its training data. As one widely-shared breakdown of the phenomenon puts it, purple and Inter win because they are the literal statistical center of "nice modern web UI." Tailwind shipped bg-indigo-500 as a prominent example years ago, that hue saturated tutorials and component demos, and a model trained on all of it now associates "nice modern button" with that exact color.

Stack shadcn/ui on top and it compounds. With no design system in context, the agent has nothing to work from except its training distribution, and the center of that distribution looks like shadcn with a gradient, because that is what millions of public templates look like. This is not a Cursor bug. Claude Code, Codex, v0, and Bolt all converge on the same look for the same reason. The output is the weighted average of every interface the model has ever seen, and the average is bland by construction.

So the fix is not a cleverer prompt. "Make it look modern" or "make it premium" just moves you a little inside the same cloud of averages. The fix is to remove the ambiguity: put a real, specific design reference in the context window so the highest-probability answer stops being the generic one.

what the usual advice gets half right

The better guides in this space already sense the shape of the answer. The common recommendation is to feed Cursor real production code instead of a text prompt: capture the actual HTML and CSS from a live site, paste it in, and iterate against it. Teams that do this report meaningfully fewer back-and-forth cycles, because the agent is finally reasoning about concrete values instead of imagining them.

That instinct is correct, but the mechanics are rough. Pasting raw HTML and CSS dumps thousands of tokens of markup, framework noise, and utility-class soup into the context, most of which is irrelevant to the design. It also means copying someone's literal bytes, which is not a clean footing to build a product on. The other popular route is a Figma MCP server, which is genuinely great when the design already lives in a Figma file. But most of the time the reference you want to learn from is a live website, not a file you own.

There is a gap between those two options: a way to turn any public URL into a compact, structured design reference an agent can build from, without copying the site and without needing a Figma file. That is the job uiscanner does.

the fix: give the model a real reference over MCP

uiscanner reads a public page and returns a design teardown: tokens (colors, fonts, type scale, radii, spacing, shadows, motion), a section-by-section structure, and a build prompt tailored to recreate the look. It reads the rendered page with vision plus the DOM, so it catches what a raw scrape 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). It describes and tokenizes a page and never copies or re-hosts the original asset bytes, so you rebuild in your own stack from the tokens and structure.

It runs as an MCP server, which is exactly the interface Cursor uses to pull in outside context. One line wires it in:

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

Cursor reads MCP servers the same way, so once it is registered your agent gets five tools it can call mid-build:

The setup page at https://uiscanner.com/mcp covers every client (it is a docs page, not a hosted endpoint; the server runs locally over stdio). There is also a CLI if you would rather script it:

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

before and after

Say you are building a landing page and you want it to feel like Stripe, not like every other AI landing page.

Before, your prompt is a wish:

Build a SaaS landing page hero. Make it look clean and modern like Stripe.

Cursor has no idea what "like Stripe" means in tokens, so it returns the average: indigo gradient, centered headline, three cards. You did not describe Stripe, you described the training distribution.

After, you give it the reference first. In Cursor's agent, one instruction does it:

Use the uiscanner MCP: run ui_teardown on stripe.com with target "landing".
Build our hero from the returned tokens, section structure, and build prompt.
Keep our brand copy; borrow the layout, type scale, spacing, and motion.

Now the agent is not guessing. It has the actual type scale, the real spacing rhythm, the gradient treatment, the section order, and a prompt written to reproduce that language in your stack. The output stops looking like a template because the highest-probability answer is no longer the generic one: you replaced the ambiguity with a specific system. If you later decide the same reference should drive a dashboard instead, call retarget_teardown and the prompt is re-tailored to that archetype (landing, dashboard, marketing, ecommerce, portfolio, mobile, general) without spending another scan.

a workflow that holds up

The point is not to clone one page. It is to give your agent taste on tap. A practical loop looks like this:

1. Find two or three real pages whose design language you admire. Browse example teardowns if you want to see the output shape first.
2. Run ui_probe to confirm a URL is scannable, then ui_teardown on the ones worth learning from.
3. Hand the tokens, structure, and build prompt to Cursor as the reference for the screen you are building.
4. Keep your own copy, content, and brand. Borrow the system, not the words.

Every scan returns an id and a shareable uiscanner.com/t/<id> link, so a reference you pull once can be reused across a whole feature without re-scanning. And because the teardown is structured data rather than a wall of markup, it costs a fraction of the context that pasting raw HTML would, which leaves Cursor more room to actually reason about your code.

the honest version of "study the best"

Reputable tools here are transformative, not extractive. uiscanner tokenizes and describes a page so you can rebuild the language in your own stack, and it never re-hosts the original assets. That is the only version of learning-from-the-best that is fair to the sites you learn from, and it happens to be the version that produces better code, because tokens and structure travel cleanly into an agent while copied bytes do not.

If you want to see what a finished reference looks like before wiring anything up, read the full Stripe teardown or the Linear teardown, or see how uiscanner differs from a plain CSS inspector in uiscanner vs Snable. Then connect the MCP server with the one-liner above and stop letting Cursor default to the average.

The free plan includes 5 scans per rolling 30 days, and paid plans (Indie at 100 scans, Studio at 400) share the same quota across the web app, MCP, and CLI. Point it at a page worth learning from, hand your agent the teardown, and the generic look goes away because you finally told the model what "good" means.