Table of Contents
🌏 中文版
The shadcn/ui post covered its core claim: components shouldn't be black-box dependencies; they should be source code copied into your repo. But many people stop at "shadcn = a set of nice components" and miss the bigger thing — it turned that distribution model into open infrastructure. The registry is a protocol anyone can implement, and the MCP server added in 2025 opens that distribution channel directly to AI agents. This post covers that layer.
Two old roads, both flawed
The npm problem was covered in the selection overview: customization is limited to the holes props leave open; deep changes mean forks or patches; upgrades can betray you. Raw copy-paste is the mirror image: total freedom, but no dependency resolution (paste one component, then chase the three utility functions it imports), no version semantics, no install tooling.
The registry is the third way: keep copy-paste's ownership model, add package management's engineering.
How a registry works
A registry is essentially a set of JSON endpoints. Each item describes: the source files (contents embedded inline), the target path, npm dependencies, and dependencies on other registry items. The CLI consumes the JSON:
# The official registry
npx shadcn@latest add button
# Any third-party registry — just point at a URL
npx shadcn@latest add https://elements.ai-sdk.dev/api/registry/all.jsonThe CLI resolves the dependency graph, installs npm deps, and writes the source into the directory you configured (paths, aliases, and Tailwind settings are declared in the project's components.json). After that the registry's job is done — the code is yours, with no runtime umbilical.
The second command is the key point: the registry is an open protocol, not shadcn's private warehouse. The official docs (ui.shadcn.com/docs/registry) walk you through hosting your own. AI Elements is a complete case study — Vercel didn't invent a new distribution mechanism for it, it implemented the registry protocol so the existing shadcn CLI just consumes it. Choosing to piggyback on the existing channel says the quiet part out loud: the registry is a de-facto standard. Design-system teams do the same — an internal component library as a private registry, and every new project adds its way to a compliant starting point without publishing an npm package.
MCP: wiring the channel to agents
In 2025 shadcn shipped an official MCP server. The docs define it in one line: "The shadcn MCP Server allows AI assistants to interact with items from registries." Connected, an agent can browse what a registry offers, read component source and usage, and run the install.
Think through what that means: the consumer of component distribution shifts from human to agent. The traditional flow is a person browsing a docs site, picking a component, copying an install command. The MCP flow is you telling the agent "build a chat input with attachment upload" — it queries the registry, finds PromptInput, installs it, wires it to your backend. The docs site turns from a showroom for people into an API for machines — the same trend as llms.txt, in two facets: one makes docs machine-readable, the other makes components machine-installable.
And the copy-in model shows a second layer of agent-friendliness here (the first being that installed code is grep-able and editable): the install action itself is reviewable. When an agent installs an npm package, your diff shows one new line in package.json; when it installs from a registry, the diff shows the complete incoming source. For a workflow where every agent-written line should pass review, that transparency is a qualitative difference.
Trade-offs
This road isn't free. Updates are on you: when upstream fixes a bug, you pull and merge the new version yourself — no one-shot npm update. As installed components accumulate, the line between "code you wrote" and "code you installed" blurs; directory discipline matters. The ecosystem in practice is predominantly React + Tailwind — though to be precise, the protocol itself has been framework-agnostic since mid-2025's universal registry items; the docs now state it "works with any project type and any framework, and is not limited to React," and the Vue/Svelte worlds run their own registries through the shadcn-vue and shadcn-svelte ports. Trust: third-party registry code lands in your repo and runs, so vetting the source is no less necessary than vetting an npm package — with the saving grace, as above, that the review is actually more feasible.
Overall
The registry upgrades "components are your code" from one project's product philosophy into an open distribution layer with a CLI, a schema, and an MCP entry point. It suits design systems and AI interface blocks — things you install precisely in order to customize deeply; it makes no sense for pure logic libraries (nobody should copy-in date-fns). Looking forward, the consumer of components is increasingly an agent — and whoever's distribution channel is machine-friendly grows the faster ecosystem. That is exactly why this topic gets its own post in the series.
References
Loading...