shadcn-ui-mcp-server: shadcn/ui Component Source for MCP Clients
A mcp server to allow LLMS gain context about shadcn ui component structure,usage and installation,compaitable with react,svelte 5,vue & React Native
At a glance
- What is it?
- A TypeScript MCP server that fetches shadcn/ui v4 source, demos and metadata from GitHub for React, Svelte, Vue and React Native. The judgement: it is a thin, cache-backed proxy, so its value depends entirely on your GitHub token and on whether your assistant needs component text at all.
- Who is it for?
- Adopt it if your assistant already works in a shadcn/ui project and keeps inventing component APIs instead of reading them, and if you are willing to supply a GitHub token so the 60 requests per hour anonymous ceiling does not become your ceiling. Skip it if you are not on shadcn/ui, or if your editor can already read node_modules.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 122 days ago.
- What is it written in?
- Mainly TypeScript, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The gap this fills between an assistant and a component library
shadcn/ui is not a dependency you install and import. The components live in your repository as source files you own and edit. An assistant that has not read those files will guess at prop names, at the composition of subcomponents, and at which primitive library sits underneath. The README frames the server as a way to give AI assistants access to shadcn/ui v4 components, blocks, demos and metadata, and that is the whole scope. It is a retrieval layer, not a code generator and not a registry client that writes files into your project. The audience is narrow and identifiable: developers running an MCP-capable client (Claude Desktop, Claude Code, Cursor or VS Code per the integration docs) inside a project that uses one of the four supported implementations. If your project does not use shadcn/ui, the server has nothing relevant to return.
GitHub is the backing store, and the cache is the mechanism
The architecture is a proxy. The server does not bundle component source; it calls the GitHub API to read the upstream repositories and serves the results to the MCP client as tools. The README lists the sources explicitly: shadcn/ui for React, shadcn-svelte maintained by huntabyte, shadcn-vue maintained by unovue, and react-native-reusables maintained by Founded Labs. Framework selection is a startup flag, so one process serves one implementation at a time. The README describes smart caching with rate limit handling, which is the part that matters operationally: without a token the anonymous GitHub ceiling is 60 requests per hour, and with a personal access token it is 5000. The README states that the token needs no scopes. Everything the assistant sees is therefore a snapshot of upstream repositories at fetch time, filtered through GitHub's API, not a curated index. If a component changes upstream, you get the new text on the next uncached fetch, and there is no version pinning described in the README.
Running it: npx, flags, and the environment variables that matter
The shortest path is the documented npx invocation: npx @jpisnice/shadcn-ui-mcp-server. Add a token with --github-api-key ghp_your_token_here, or export GITHUB_PERSONAL_ACCESS_TOKEN instead. Framework switching is --framework svelte, --framework vue or --framework react-native, with React as the default. For React only, --ui-library base swaps the primitive layer away from the default Radix setup, and the same choice is available as UI_LIBRARY=base. Claude Desktop users can take the .mcpb route from the releases page: download the file, double-click it, enter a token, install. For HTTP-based clients the README documents SSE mode, node build/index.js --mode sse --port 7423, and registering it with claude mcp add --scope user --transport sse shadcn-mcp-server http://localhost:7423/sse. Transport modes are stdio (default), sse and dual, settable through MCP_TRANSPORT_MODE, with MCP_PORT, MCP_HOST and MCP_CORS_ORIGINS alongside it. Docker Compose is offered as the recommended container path, with a health endpoint at /health. Note that the SSE and Docker instructions assume a built artifact at build/index.js, which the README does not show you how to produce.
Where the design creates friction
The most consequential limitation is the rate limit, and it is not a footnote. Anonymous usage is capped at 60 requests per hour against the GitHub API. A single question about a component's demo, its metadata and its dependencies can consume several of those, so an untokened setup degrades quickly into failures. The README treats the token as recommended; in practice it is close to required. Second, the server is only as current as the upstream repositories it reads, and the README does not document a pinning mechanism, so an assistant can describe a component version that does not match the one vendored in your project. That is a real failure mode for teams that copied components months ago. Third, one process serves one framework and, for React, one primitive library. A monorepo mixing React and Svelte needs two server entries with different --framework values. Fourth, the framework coverage is not symmetric: the UI library switch is React only, and the four implementations are maintained by different people, so metadata quality will vary by source repository. The README does not describe how it handles a missing file or a renamed component upstream.
Compared with letting the assistant read your working tree
The obvious alternative is not another MCP server. It is file access. Most MCP-capable clients can already read your repository, and in a shadcn/ui project the component source is sitting in your working tree, exactly as you have customised it, with no API calls and no rate limit. That approach wins on fidelity, because it reflects your edits, and on cost, because it is free. The trade-off is scope and convenience: a filesystem tool gives the assistant whatever is on disk, while this server gives it upstream demos, block implementations and dependency metadata that may not exist locally, plus directory browsing across the source repositories. If your components are heavily modified, upstream text is actively misleading and the filesystem is the better tool. If you want the assistant to reason about how a block is composed before you copy it in, the server has material your disk does not.
Maintenance, releases and the MIT licence
The project is MIT licensed, which permits commercial use, modification and redistribution provided the copyright notice and permission notice are retained. That is a permissive arrangement, but it is not legal advice and does not settle questions about the licences of the upstream component repositories the server reads; those are separate projects with their own terms, and copying their source into your application is a decision made independently of this server's licence. On maintenance, the release history in the supplied material shows v1.0.1 in June 2025, v1.1.4 in October 2025, and v2.0.0 in January 2026, with the last push to the default branch in May 2026. The v2.0.0 label alongside a README titled for shadcn/ui v4 suggests the major version tracks the upstream component generation. Upgrade cost is mostly configuration drift: if a future release changes flag names, transport defaults or the UI_LIBRARY semantics, your Claude Desktop args array and any Docker environment block are what you edit. Nothing in the README describes a migration guide, so pinning a version in your client config is the conservative move.
Editorial conclusion
Adopt it if your assistant already works in a shadcn/ui project and keeps inventing component APIs instead of reading them, and if you are willing to supply a GitHub token so the 60 requests per hour anonymous ceiling does not become your ceiling. Skip it if you are not on shadcn/ui, or if your editor can already read node_modules. Before trusting it, run the server once with --framework set to the implementation you actually use, confirm the tool list your client sees, and check whether UI_LIBRARY=base is the right primitive library for your React setup, because the default is radix.
Community notes