This server provides coding agents with live access to shadcn-style UI component registries, enabling them to discover, fetch, compare, and validate open-source UI components.
List Registries (list_registries): Discover available component libraries (e.g., ReUI ~1534 components, Kokonut UI ~40, Kibo UI ~41), including their IDs, names, and homepages.
Search Components (search_components): Perform synonym-aware, token-ranked searches across all or specific libraries (e.g., "modal" finds "dialog"). Returns lightweight results filterable by type (ui, block, component, hook) and optionally restricted to verified/installable components only.
Get Component (get_component): Fetch the full, current source code of a specific component, including file contents, npm and registry dependencies, and the exact npx shadcn add install command.
Compare Components (compare_components): For a given UI intent (e.g., "pricing table"), fetch the best match from each library side by side, showing dependencies, file count, lines of code, install command, and source previews — so you can pick the best implementation.
Check Consistency (check_consistency): Analyze a set of components for design clashes, including inconsistent border-radius, hardcoded colors vs. theme tokens (with suggested remappings like text-zinc-900 → text-foreground), missing dark-mode variants, arbitrary spacing/font values, and conflicting icon or animation libraries — with concrete per-component fix suggestions.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@ui-registry-mcp Search for pricing components across all registries"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Coding agents are great at logic and not so good at taste. Ask one to build a pricing page and it'll hand-roll a flat, generic card from memory - when there are thousands of beautiful, open-source components sitting one fetch away that too built by people who are great UI/UX experts.
This is an MCP server that closes that gap. It plugs into Claude Code, Cursor, Windsurf, or any MCP client and lets the agent reach into 12 real component libraries — search them, pull the actual source, compare options, and check that everything looks like it belongs together — while you stay in your editor.
The idea is simple: the agent keeps the judgment (what to use, how to compose, what to tweak). The libraries keep the craft. This server is just the bridge.
No cloning, no build. Point your MCP client at the published package:
{
"mcpServers": {
"ui-registry": {
"command": "npx",
"args": ["-y", "ui-registry-mcp"]
}
}
}(In Claude Code you can also just run claude mcp add ui-registry -- npx -y ui-registry-mcp.)
Then ask for UI as:
"Build a cool pricing section - look across the libraries and pick the best component or tweaking them makes up a great pricing page."
"Add a data table and make sure it matches the card above."
Behind the scenes the agent searches, compares, pulls real code into your project, and does a quick design-consistency pass before it's done. It'll also tell you which library each piece came from, so you can credit and inspect the original.
Related MCP server: shadcn MCP Server
Twelve libraries, roughly 3,700 components, all fetched live — so you always get the current version, never a stale copy.
Library | Components | Notes |
~1,534 | Huge range; some blocks are paid — the server filters those out | |
~1,066 | Large set, leans web3/DeFi | |
~116 free | Animated, 3D, bento; most of its catalog is Pro | |
~210 | Marketing sections — hero, pricing, testimonials | |
~157 | Design-engineer components with motion | |
~107 | Micro-interactions | |
~79 | Accessible, built on Base UI | |
~77 | Vercel's chat / AI-native components (Apache-2.0) | |
~64 | Motion toolkit | |
~41 | Data-heavy — tables, kanban, gantt | |
~40 | Flashy standalone cards | |
~26 | Animated layouts |
Everything the server hands you is openly licensed and free for commercial
use — MIT across the board, except Vercel's AI Elements, which is Apache-2.0
(keep its license notice when you ship). A couple of libraries (ReUI, Aceternity)
also list premium components in their catalog — those quietly fail to install.
You don't have to think about it: ask for verified results and the server only
returns things you can actually use. Still, check a library's own license before
you ship.
Adding another library is one entry in src/registries.ts
if it exposes a standard shadcn registry — nothing else changes.
Six tools, meant to be used roughly in this order:
list_registries — what libraries are available, with their licenses and
any "heads up, this one has paid components" notes.
search_components — describe what you want in plain words. It understands
synonyms (ask for a "modal", it finds "dialog"), and returns just names and
one-line descriptions so it never dumps a wall of code into the conversation.
Add verified when you only want components that are actually installable.
compare_components — the same idea (say, a "pricing table") pulled from
every library at once, side by side, so the agent picks the best one instead
of the first one.
get_component — the real source for one component: every file, its
dependencies, the exact npx shadcn add command, and where it came from.
check_consistency — the part that makes mixed components feel like one
design. It reads the actual code and flags the little clashes — one component
rounds its corners more than another, one hardcodes zinc-900 where the rest
use your theme, one forgot dark mode — and suggests the fix for each.
list_components — the full directory, every component with its direct
URL, if you want to browse or link to sources.
If you just want to use it, everything above is enough. What follows is the how and the why — for the curious, and for anyone thinking about contributing.
A few choices worth explaining, because they're the difference between a demo and something you'd actually keep installed:
It fetches live instead of mirroring. These libraries ship updates constantly. A cached copy would rot; pulling from each registry's own endpoint means you always get today's version. A short in-memory cache keeps it snappy within a session.
It's honest about paid components. Rather than let the agent confidently pick something that 401s on install, premium items are flagged up front and filterable. Nothing worse than an agent that recommends what it can't deliver.
Consistency is the real value, not just fetching. Anyone can wrap a registry. The thing that actually makes agent-built UI look designed is catching the token/spacing/radius drift when you mix sources — so that's a first-class tool, not an afterthought.
It gives credit. Every component comes back with its source URL and a ready-to-show attribution line, and the agent is told to pass that on. You should always know whose work you're building on.
One dead library can't sink a search. Requests retry on hiccups, and a registry being down just drops it from the results instead of failing the whole call.
npm install
npm run build
npm test # spins up the server and exercises every tool end-to-end
npm run smoke # quick check that all the registries are reachable
npm run catalog # dump the whole directory to catalog.jsonIt's genuinely useful today, but two things would take it further, and both are real projects rather than quick wins:
Visual previews. You pick UI with your eyes, and right now the agent picks from text. The catch: these libraries don't expose preview images consistently, so doing this properly means rendering and screenshotting components — infrastructure, not a config flag.
Meaning-based search. Search understands synonyms today, but not intent like "something friendly for an onboarding screen." Real embeddings would fix that.
This exists so an agent can build UI that doesn't look like every other agent's UI — and it gets better every time someone actually uses it and tells me what broke or what was missing. If you hit a rough edge, have a feature idea, or know a library that belongs in here, please open an issue. I genuinely want to hear it.
Pull requests are very welcome — especially new registries (usually a
few-line addition in src/registries.ts) and better
consistency checks. See CONTRIBUTING.md to get set up, and
CHANGELOG.md for what's changed. If it saved you some time, a ⭐
on the repo means a lot and helps other people find it.
A real thank-you to the teams behind the libraries this stands on — ReUI, Aceternity, Tailark, Cult UI, SmoothUI, Optics, beUI, Kibo, Kokonut, useLayouts, Watermelon — and to the shadcn registry ecosystem that makes them all fit together. This is a bridge to their craft; none of it works without them.
MIT licensed.
Given a set of components (from get_component / search results), statically analyze their source for design clashes when mixed together: inconsistent border-radius scales, hardcoded colors vs theme tokens, missing dark-mode variants, and conflicting icon/animation libraries. Returns findings with concrete pointers so you can normalize the UI before shipping. Run this after assembling components from different libraries.
| Name | Required | Description | Default |
|---|---|---|---|
| components | Yes | The components you plan to use together |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the tool performs static analysis (no side effects), returns concrete findings with pointers, and checks specific design dimensions. It does not discuss auth needs, rate limits, or performance, but the static nature and output type are adequately communicated for a read-only analysis tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences with no wasted words. It front-loads the core action, lists specific checks, describes the output, and ends with usage timing. Every sentence is informative and earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of output schema, the description adequately explains that returns are findings with concrete pointers and lists the categories (border-radius, colors, dark-mode, icon/animation libraries). It covers the tool's complexity well, though it could detail the output structure slightly more. The usage context (after assembling from different libraries) adds completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers 100% of parameter descriptions, so the baseline is 3. The description adds context about the data source ('from get_component / search results') but does not deepen meaning beyond what the schema already provides (name and registry). It marginally hints at usage context but no new parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb-statically analyze design clashes-and clearly identifies the resource (components from get_component/search). It enumerates specific clash types (border-radius scales, hardcoded colors, missing dark-mode, conflicting libraries), which distinguishes it from sibling tools like compare_components (direct comparison) or get_component (single component details).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use the tool: 'Run this after assembling components from different libraries.' This implies the prerequisite actions (gathering components via get_component/search) and the post-assembly timing. It does not provide when-not-to-use scenarios or explicitly name alternatives, but the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
For a given intent (e.g. 'pricing table', 'date picker'), fetch the single best match from EACH library and return them side by side: dependencies, file count, lines of code, install command, and a source preview. Use this to choose the nicest implementation instead of taking the first search hit.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | The component intent, e.g. 'pricing table' | |
| registries | No | Optional subset of registry ids to compare (default: all) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but the description details what the tool returns (dependencies, file count, lines of code, install command, source preview). It is implied to be a read-only fetch and compare, but could explicitly state lack of side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, efficiently conveying purpose, output, and usage guidance. Every word adds value; no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 2 parameters and no output schema, the description provides complete context: what it does, what it returns, and when to use it. No gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already documents both parameters. The description adds value by clarifying 'query' as component intent and 'registries' as optional subset of registry ids, enhancing understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool compares components across libraries for a given intent, with examples like 'pricing table'. It distinguishes from siblings by contrasting with 'taking the first search hit' from search_components.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says when to use: to choose the nicest implementation instead of taking the first search hit. This provides clear usage context and differentiates from search_components.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch the full, current source of one component from a specific library: file contents, npm dependencies, registry dependencies, and the exact install command. Use this after search_components. The returned source is real code you can drop into the project and edit freely.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Component name exactly as returned by search_components | |
| registry | Yes | Registry id, e.g. 'reui' (see list_registries) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It describes the return content as 'real code you can drop into the project and edit freely', but does not explicitly state it's a read-only operation or disclose any side effects, auth needs, or rate limits. Adequate but not comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences: first sentence states core purpose, second lists contents, third gives usage guidance and output nature. No wasted words, information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given low complexity (2 params, no output schema), description explains return content (file contents, dependencies, install command) and states it's editable code. Lacks explicit structure or format of the returned source, but provides sufficient context for a simple tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with both parameters described. Description does not add significant extra meaning beyond the schema, such as constraints or format details. Baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it fetches the full current source of a component from a specific library, listing included contents (file, dependencies, install command). It distinguishes from sibling tools like search_components, which find components, and list_registries, which list registries.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'Use this after search_components', providing clear context for when to use. It does not mention alternatives or when not to use, but the guidance is specific and helpful.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the component libraries this server can pull from (id, name, homepage). Call this first to see what is available.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It only states it lists registries with basic fields, but does not disclose read-only behavior, potential empty results, or any side effects. Minimal behavioral info beyond purpose.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, front-loaded with the action, and no wasted words. It is appropriately sized for a simple tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter list tool with no output schema, the description covers the purpose, output fields, and usage order. It is fairly complete, though it could mention potential errors or empty results.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters, so baseline is 4. The description adds meaning about the output fields, which is useful for understanding the tool's output.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'List' and resource 'component libraries', and specifies the output fields (id, name, homepage). It distinguishes from sibling tools like get_component (detail) and search_components (search).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly advises to call this tool first to see available registries, providing clear context. It does not mention when not to use it, but the directive is strong enough to guide the agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search all configured component libraries (or one) for components matching a natural-language query, e.g. 'pricing table', 'date picker', 'sidebar'. Synonym-aware: 'modal' also finds 'dialog', 'dropdown' finds 'select', etc. Returns a ranked, lightweight list (registry, name, type, title, description) — NOT the source. Pick the best match, then call get_component to fetch its real code.
| Name | Required | Description | Default |
|---|---|---|---|
| type | No | Optional type filter: 'ui' (single component), 'block' (composed section), 'component', 'hook' | |
| limit | No | Max results (default 20) | |
| query | Yes | What you need, e.g. 'pricing table' or 'avatar group' | |
| registry | No | Optional registry id to restrict the search (see list_registries) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses synonym-aware behavior (modal/dialog, dropdown/select), the return format (registry, name, type, title, description), and clearly states it does NOT return source code. This is comprehensive and leaves no surprises.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (four sentences), front-loads the core purpose, and efficiently uses examples and hints. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 4 parameters, full schema coverage, no output schema, the description explains the return format (lightweight list with fields) and ranking. It is complete enough for an agent to use the tool effectively without additional information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds value by explaining the natural-language nature of the query, giving synonym examples, and clarifying optional filters with concrete values (ui, block, component, hook). It enhances understanding beyond schema alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: search across component libraries for components matching a natural-language query. It provides examples ('pricing table', 'date picker') and explicitly distinguishes from sibling tool get_component by stating it returns a lightweight list, not the source. This leaves no ambiguity about what the tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description advises to 'Pick the best match, then call get_component to fetch its real code,' which provides a clear usage pattern. However, it does not explicitly state when not to use this tool or specify alternatives beyond get_component, so a slight deduction from a perfect score.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.0check_consistencycompare_componentsget_componentlist_registriessearch_componentsScored across 5 tools
Each tool has a clearly distinct purpose: listing registries, searching components, fetching full component source, comparing alternatives across libraries, and checking design consistency. No two tools overlap in functionality.
All tool names follow a consistent verb_noun pattern with underscores (e.g., list_registries, search_components, get_component, compare_components, check_consistency). There is no mixing of naming conventions.
With 5 tools, the surface is well-scoped for the server's purpose: discover libraries, search and retrieve components, compare options, and validate consistency. Each tool earns its place without being excessive or insufficient.
The tool set covers the full workflow from listing registries to searching, retrieving, comparing, and checking consistency. There are no obvious gaps for the intended use case of exploring and integrating UI components from multiple registries.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Find UI components and themes, retrieve code, and generate with hosted 21st AI when enabled.
Search GitHub, npm, PyPI, StackOverflow, ArXiv from one MCP — built for coding agents.
AI Agent Source Registry. 288K+ curated sources for agentic search and discovery.
Live React design-system APIs, patterns, and code validation so AI agents build real UI, not slop.
