Give Your AI Coding Tool a Design Library (MCP, Explained Simply)

There are two ways to give an AI coding tool good design direction. The first is manual: find a well-designed section, turn it into a detailed prompt, paste it into the chat, repeat for every section of every page. It works — it is how most people use a prompt library today. The second way is newer: connect the library to the tool itself, so the AI can search it and pull what it needs mid-task, without you ferrying text between tabs.

That second way runs on MCP, and it is worth fifteen minutes of your attention even if you never read a protocol spec in your life.

MCP in one paragraph

MCP — the Model Context Protocol — is an open standard, introduced by Anthropic in late 2024, for connecting AI assistants to outside tools and data. An MCP server exposes capabilities ("search this library", "fetch this document", "query this database"); an MCP client — Cursor, Claude Code, Windsurf, VS Code’s Copilot, and most serious AI editors now — lets the model call those capabilities while it works. Think of it as USB for AI tools: one standard plug, and anything that speaks it can connect to anything else that does.

Why this matters for design, specifically

AI models are good at writing code and bad at inventing taste. We covered the result in Why AI-built websites all look the same: leave design decisions unspecified and the model fills them with the internet’s average. The cure is feeding it real, specific design decisions — and that is exactly the kind of context MCP is built to deliver at the right moment.

The difference is where the knowledge lives. A pasted prompt is frozen: whatever you copied, the model gets, once. A connected library is live: while building your pricing page, the agent can search for pricing sections, compare a few, pull the full spec of the one that fits, and keep your established tokens — because the library is a tool call away instead of a tab away.

In practice the workflow collapses from six steps to one sentence. Instead of browse, pick, copy, switch, paste, pray — you write: "Search the library for a dark editorial hero, adapt the best match to our product, keep our type scale and palette." The agent does the fetching.

What a design-library MCP server should give you

Not every MCP server earns a slot in your config. For design work, look for three things.

First, searchable sections, not just whole templates — real pages are assembled section by section (a hero, a feature grid, a pricing table), and the server should let the agent find each one by type, style, or industry.

Second, full specs rather than screenshots. The agent cannot use a picture; it needs the decisions written out — layout structure, type pairing and scale, spacing rhythm, colors as tokens. A good library entry reads like instructions from a designer, because that is what it is.

Third, internal consistency. Sections pulled from one designed system share DNA, so a hero and a pricing table fetched separately still look like the same site. Random snippets from the internet do not give you that; a curated library does.

Setting it up

The mechanics are similar in every MCP-capable editor: you add a server entry to the tool’s MCP configuration — a command to run, or a URL for a remote server — restart or refresh, and the server’s tools appear to the agent automatically. Cursor has an MCP section in its settings; Claude Code adds servers with a one-line command; Windsurf and the rest follow the same shape. The server’s own page always has the exact snippet, which beats retyping it from a blog post.

For the worked example: Jiro’s MCP server connects our library — over a thousand designed sections and templates, written as specs — to whatever editor you use. The setup for each editor lives at jiro.build/mcp, and once connected, the flow above is literal: ask your agent for a section in a style, and it pulls the spec from the library into context.

One honest caveat, because it is early days for MCP everywhere: a server runs with whatever access your editor grants it, so treat your MCP config like your extensions list. Add servers you trust, know what each one can do, and skim what the agent fetched before you ship it.

A real example: the pricing page

Here is what this looks like on an actual task. You are building a pricing page in Claude Code with a design-library server connected. You write: "Find a pricing section that fits our dark editorial style — three tiers, one highlighted — and build it with our existing tokens." The agent searches the library, fetches the matching spec, and generates the section using your established palette and type scale. Total new design decisions you had to invent: zero. Total design decisions in the output: all of them, made by a designer.

Whether you then run that spec through Cursor, Claude Code, or paste it into one of the chat builders is a stack preference — we compared those in Bolt vs Lovable vs v0. The library does not care which tool it feeds.

The quiet shift

The first wave of vibe coding proved that anyone can ship a website by describing it. The current wave is about shipping one that looks deliberate — and the pattern that makes it repeatable is exactly this: keep the taste in a library, keep the labor in the agent, and connect the two with a standard instead of a clipboard. MCP is not magic. It is just the first time your design reference and your coding tool have spoken the same language.