shadcn ecommerce blocks: what exists and what's missing

You can buy or copy a shadcn product page today. What you cannot get from any of these registries is the part of the page that raises the basket.

We read the public category indexes of the main registries on 24 August 2026. CommerCN lists eight categories: checkouts, carts, reviews, orders, categories, product details, products, promo banners — free, copy-paste, no npm install. Tailwind Plus lists 14 ecommerce categories and 84 components: product overviews, product lists, category previews, shopping carts, category filters, product quickviews, product features, store navigation, promo sections, checkout forms, reviews, order summaries, order history, incentives — paid. shadcnblocks has ecommerce categories for product list, product detail, product card, shopping cart (14 blocks) and checkout (8 blocks), inside a much larger catalogue advertised as 1,837+ blocks on its pro tier. shadcnstore and shadcnstudio cover similar ground.

That is a genuinely good supply of layout. It is also, in every case, the display half of a store.

The four that are missing

Checked against the category listings named above. We read indexes, not all 1,837 blocks, so treat this as "not surfaced in any category" rather than "provably absent from every file".

The quantity tier selector. Buy 1, buy 2 save 15%, buy 3 save 22%. The most common average-order mechanism in DTC, and it appears in no ecommerce category on any of these registries. What every registry does have is a SaaS pricing table, which looks similar and is a different component: a pricing table sells one subscription among plans, a tier selector sells more units of one product, and it is a radio group of cards rather than a stepper. Substituting one for the other is the most common reason a generated store's bundle block looks wrong.

The free-shipping progress bar. "You are 12 euros from free shipping", with a fill. It needs three inputs — cart total, threshold, currency — and a rule about when it appears and when it congratulates. Not a hard component. Not in any index we read.

The chained complement. A single named add-on offered after the add-to-cart, with an unchecked box and a plain decline. This one carries constraints beyond layout: Article 22 of the EU Consumer Rights Directive makes a pre-ticked box a refundable charge, so the default state is not a design preference. A registry block that ships pre-checked is a liability, which may be exactly why nobody ships one.

The sticky mobile add-to-cart. A bar that pins the price and the button once the hero scrolls past, on the viewport carrying most of the traffic. Shopify themes have had this for years. The shadcn registries do not surface it.

How an agent reaches any of this

The mechanism is the useful part of this article, because it generalises past these five registries.

pnpm dlx shadcn@latest mcp init --client claude sets up the shadcn MCP, and the important property is that it browses any shadcn-compatible registry declared in your components.json, not only the default one. Registries are namespaced, can require auth headers, and can be private. So the MCP is really a transport: whatever registry you point it at, the agent can search it by name or function and install from it conversationally.

That means the answer to "my agent keeps writing generic commerce components" is not necessarily a new MCP. It is often a registry entry in components.json pointing at a library that has what you need — and, today, the shortage is on the registry side rather than the transport side.

Manual installs still work exactly as before: npx shadcn@latest add <url> against a registry item URL.

Which one to use for what

• Prototyping fast, budget zero: CommerCN. Copy-paste, own the code, eight solid categories.
• A real store, and the merchant will pay once: Tailwind Plus. 84 components, made by the Tailwind team, and the quality of the responsive behaviour is the reason to pay.
• Breadth, many pages, marketing plus store: shadcnblocks, for the size of the catalogue.
• The four components above: none of them. Write them, and treat the spec as part of the deliverable rather than an implementation detail.

We are not ranking these against each other on quality, because we have not built the same page in all five and measured it — and a comparison without that is an opinion dressed as a finding.

Why the gap exists

Component libraries are built by people who build interfaces, and the four missing pieces are commerce mechanics rather than interface patterns. A quantity tier is a pricing decision with a UI attached; a shipping bar needs a cart; a complement needs a legal default. None of them is hard to render, and all of them require knowing something about selling before you can specify them.

The same gap shows up one level up: we searched the official MCP registry on the same day and ui components, component library and upsell each return zero servers, while ecommerce returns 21 — every one of them a data connector. The full picture of what MCPs exist on either side of that line is here.

What to do with this

If you are an agent assembling a storefront: install the shadcn MCP, add whichever registry fits the budget, take the layout from it, and hand-write the four mechanics. If you skip them, the page you produce will be a well-composed catalogue rather than a store — which is the commercial version of looking generated, and it is the version that costs the merchant money.

Disclosure — we are building uxgen, which targets exactly those four components; they are shown running here. It is not installable yet, and every registry named above is a real, working alternative today.