Guide · glossary
what is MCP (Model Context Protocol), and why designers should care
If you build interfaces and you have used Cursor, Claude Code, or Codex lately, you have probably watched an AI agent invent a color that is close to your brand blue but not it, rebuild a button that already exists in your system, and drift a little further from your design language on every screen. The fix for that drift has a name, and it is a protocol, not a product. It is called MCP, the Model Context Protocol, and it changes what an agent is allowed to know about your work.
what MCP actually is
MCP is an open standard, introduced by Anthropic in November 2024, for connecting AI assistants to the tools and data where your work actually lives. The common one-liner is that MCP is USB-C for AI: one universal connector, instead of a custom integration between every model and every app. Before MCP, if you wanted an agent to read your Figma file, your database, or your ticket tracker, someone had to hand-wire each of those connections. MCP replaces that N-times-M mess with a single shared protocol that any client and any server can speak.
It is not owned by one vendor. Per Wikipedia's record of the protocol, after launch it was adopted by other major providers including OpenAI and Google DeepMind, and stewardship later moved to a foundation. So the interface you learn once works across the whole field of agents, not just one company's chat window.
Under the hood, MCP is a client-server standard built on JSON-RPC 2.0. You do not need to care about the wire format. You do need the three roles, because they explain who is allowed to do what.
the three roles, in plain terms
- Host: the app you are actually sitting in. Claude Code, Cursor, Codex, the Claude desktop app. This is what you talk to.
- Client: a connector that lives inside the host and manages one connection to one server. Mostly invisible plumbing.
- Server: an external program that exposes a specific capability. The Figma MCP server. A Postgres MCP server. uiscanner. This is the part people build and share.
So when someone says "install an MCP server," they mean: give your host a new capability by pointing it at a small program that knows how to do one thing well.
the three things a server can expose
This is the part most explainers rush past, and it is the part that decides how a tool behaves. An MCP server can offer three kinds of capability, and they differ by who is in control.
| primitive | controlled by | think of it as | example |
|---|---|---|---|
| tools | the model | a function the agent can call | "scan this URL and return its tokens" |
| resources | the app | a read-only data source, like a GET endpoint | a file, a design token export |
| prompts | the user | a reusable, parameterized instruction | "turn this selection into a React component" |
Tools are the loud primitive, the one agents reach for on their own. Resources are context the app pulls in. Prompts are recipes a person triggers. A good design-facing MCP server is mostly a well-named set of tools plus clean structured output.
why a designer should care
Here is the stake. Figma's own writing puts the failure mode plainly: without design-system context, an AI coding tool picks colors that are close to your brand colors but does not know they map to named tokens, builds components from scratch instead of pulling the ones that exist, and drifts from your system in ways that compound across every screen. That is not a model being dumb. That is a model being starved of context and guessing the statistically average value.
MCP is the pipe that ends the guessing. When an agent reads your real design context through a server, it stops hallucinating your design system and starts using the actual one. That is a design pitch, not an infrastructure one.
the Figma MCP server, as the canonical example
The clearest example is Figma's Dev Mode MCP server, announced in 2025. You select a frame in Figma, and an agent in Cursor, VS Code, or Claude Code can request live design data for that selection: layout rules, text styles, component properties, and image references. Two of its tools are worth knowing by name. get_design_context returns a structured representation of your selection that the agent can translate into any framework. get_variable_defs extracts the actual variables and styles in that selection, colors, spacing, typography, so the generated code references your tokens by name instead of inlining a hex value it made up.
The catch is that the Figma MCP server reads a Figma file you own. If the look you are chasing is a shipped public website rather than a design file on your account, the Figma server has nothing to point at. That is a real gap, because a lot of design inspiration is a live URL, not a .fig.
where uiscanner fits
uiscanner is an MCP server that covers exactly that gap: it reads any public URL, not a file you own. You paste a live page and it returns a design teardown, tokens (colors, fonts, type scale, radii, spacing, shadows, motion), a section-by-section structure, and a Claude-tailored build prompt to recreate the look. The way it reads the page is the interesting part: it reads the rendered page with vision plus the DOM, so it catches what a code scraper misses, the real primary button, a centered versus split hero, and decorative imagery that it describes as a prompt to recreate rather than something to copy.
It is transformative by design. It describes and tokenizes a page, and it never copies or re-hosts the original site's asset bytes. You rebuild in your own stack from the tokens and the structure. Every scan returns an id and a shareable uiscanner.com/t/<id> link.
As an MCP server it exposes five tools:
ui_teardown(url, target?)scans a page and returns the teardown plus its share link.ui_probe(url)is a cheap preflight that spends no scan, useful to check a URL will work first.get_teardown(id | link)re-fetches a finished teardown from earlier in the conversation.retarget_teardown(id, target)re-tailors the build prompt to another archetype (landing, dashboard, marketing, ecommerce, portfolio, mobile, general) without re-scanning.whoami()reports your plan and remaining scans.
It works as an MCP client tool for Claude Code, Cursor, and Codex. Installing it into Claude Code is one line:
claude mcp add uiscanner -- npx -y uiscanner-mcp@latest
Full setup for every client lives on the uiscanner MCP page. If you prefer the terminal without any MCP wiring, the same engine ships as a CLI:
npx -y uiscanner-mcp@latest scan stripe.com --target landing
One honest technical note, because a lot of MCP writing gets this wrong: MCP servers can run over stdio (local, same machine) or over streamable HTTP (remote). uiscanner is stdio-only. There is no hosted remote MCP URL to point a client at; the agent runs the package locally. Quota is unified across the web app, the MCP server, and the CLI on a rolling 30-day window (Free 5, Indie 100, Studio 400), so a scan is a scan wherever you trigger it.
the mental model to keep
MCP does not make an agent smarter. It makes an agent informed. The Figma server tells it what your design system says. uiscanner tells it what a page you admire is actually made of. A database server tells it what your data looks like. Same protocol, same win: less guessing, less drift, output that matches something real instead of the corpus average.
For designers, the takeaway is small and specific. You do not have to write a server. You have to know that the good tools now expose their capabilities through one, that "close enough" colors are a context problem and not a taste problem, and that the two servers most likely to change your day are one that reads the file you own and one that reads the page you want to learn from. For the hands-on version aimed at one editor, see design context for Claude Code over MCP, and for a wider survey, the best MCP servers for designers.