Ask a coding agent for a pricing section and it will write you one. It will be competent, generic, and invented from scratch, because the model has no catalogue to reach into - only a memory of what pricing sections look like. That is the actual problem MCP solves for interface work: not making the agent smarter, but giving it something real to install.
What MCP is, briefly
The Model Context Protocol is a standard way for a coding agent to call tools that live outside it. An MCP server exposes a set of tools, the agent's client connects to it, and from that point the agent can search, fetch and act through them.
For UI work the useful shape is simple: a search tool over a component catalogue, and an install tool that writes the files. The agent stops guessing at a hero section and starts choosing one.
What changes in practice
Three things, and the third is the one people do not expect.
The component is real code with a real dependency list. An invented component compiles or it does not, and either way nobody has looked at it. An installed one has been previewed by people, has its imports declared, and brings the primitives it needs.
You see it before it lands. The 21st MCP returns previews inline, so the agent's suggestion arrives as pictures rather than as a diff you have to render mentally. That is the difference between reviewing a choice and reviewing a file.
Your own components come back. Point the agent at your team's registry and it installs your button instead of writing a fourth one. This is the part that matters most in an existing codebase, where the risk is not a bad component but a duplicate one.
Setting it up
The 21st MCP works with any MCP client, which today means Cursor, Claude Code, Windsurf, Codex and the rest. The catalogue behind it is the same one this site serves, and installs run through the shadcn CLI against the registry, so nothing new enters your dependency tree.
There is a CLI as well, for the same jobs from a terminal or from CI, with an API key instead of an interactive login. The MCP and CLI page has the current setup for each client.
Prompts that produce something usable
The failure mode with an agent and a catalogue is the same as with a search box: a vague query returns a vague result.
Name the section and the constraint. "A pricing section with three tiers and a monthly and annual toggle" beats "pricing". The constraint is what makes one result better than another.
Say what it must not do. "No animation library" and "server component compatible" are the two constraints that eliminate most of a catalogue, and the agent cannot infer either.
Ask for options before code. "Show me four hero sections that use CSS rather than video" returns previews to choose between. Letting the agent pick and write in one step is how you end up reviewing a file instead of a decision.
Give it the token names. An installed component arrives with someone else's spacing and colours. If the agent knows your CSS variables, it adapts the component in the same step rather than leaving you a second pass.
What still needs a person
Worth being honest about, because this is a workflow and not a magic trick.
The agent will not notice that the component it installed has no focus-visible state, that its animation ignores reduced motion, or that its dark mode was generated rather than designed. Those are the same checks any borrowed component needs, and the guides in this blog exist largely because they are the checks people skip.
It also will not decide whether the interruption should have been a page instead of a dialog, or whether the carousel should have been a list. The catalogue answers "what exists", and the decision is still yours.
Where else to look
The honest list, because the answer is not always us:
| Source | Best for | Trade-off |
|---|---|---|
| 21st MCP | Searching and installing real components with inline previews | Installs need a membership |
| shadcn CLI | The same installs, typed by hand from any registry | You are doing the searching |
| An agent with no catalogue | Anything genuinely bespoke | Every component is invented, none is reviewed |
| A team registry | Your own components, so the agent stops writing duplicates | Somebody has to publish them first |
Taking one
Every component page has a live preview and the code. Installing goes through the shadcn CLI against our registry:
That key comes from your 21st account, and installs require a membership. Set API_KEY_21ST once in your shell and the command works for anything in the catalogue.
Frequently asked
- What does an MCP server do for UI work?
- It gives a coding agent a search tool over a real component catalogue and an install tool that writes the files. Without one, the agent invents a component from memory: competent, generic and unreviewed. With one, it chooses from components that people have previewed and whose dependencies are declared.
- Which editors support MCP?
- Any MCP client, which today includes Cursor, Claude Code, Windsurf and Codex among others. The 21st MCP connects to the same catalogue this site serves, and installs run through the shadcn CLI against the registry, so nothing new enters your dependency tree.
- How do you prompt an agent for a component?
- Name the section and the constraint, since the constraint is what makes one result better than another. Say what it must not do, because no animation library and server component compatible eliminate most of a catalogue. Ask for options before code. And give it your token names, so the component is adapted in the same step rather than in a second pass.
- What does an agent with a catalogue still get wrong?
- It will not notice a missing focus-visible state, an animation that ignores reduced motion, or a dark mode that was generated rather than designed. It also will not decide whether the dialog should have been a page. The catalogue answers what exists; the judgement is still yours.