Skip to content
MrJev

matchcn

Semantic index across shadcn-format registries: components are tagged once across six dimensions and committed, and your brief is classified at query time to match against them. Ships as an MCP server.

View on GitHub →

Hands-on review

A semantic index over shadcn registries. Its limitations section explains why one registry was withdrawn after half its components failed to install.

Good for

  • A limitations section that explains a registry it withdrew and why
  • A component index tagged once and committed, so queries stay cheap
  • Naming its own weakest tagged dimension instead of averaging it away

Watch out for

  • Your brief text goes to classifier.dev, a third party, at query time
  • `docs/DECISIONS.md` is cited from five files and is not in the repository
  • No tests; `tsc --noEmit` is the whole check

Tested Sep 22, 2026 at 2f6191528253 · node:24 in Docker, offline and then against a stand-in reached by changing one line

How we reviewed this: we ran its typecheck, tried the demo offline to see what it actually needs, then pointed its classifier client at a stand-in by changing one line and watched what left the machine. We made no Jev calls.

What it is

npx shadcn add can install from any registry publishing a registry.json, and hundreds do. Directory tools search component names, which does not help when you know what you need but not what someone called it — the README’s example is that “a pricing section with three plans” does not match simple-pricing-with-three-tiers unless you already knew the name.

matchcn tags every component across six fixed dimensions — category, motion, visual density, interaction model, and two more — then matches your brief against those tags.

Where the work happens

The tagging is done once and committed: data/ is 3.7 MB of per-registry tag files. That is the expensive part, and it does not repeat.

Your brief, though, is classified at query time. We found that by running the demo with --network none:

[TypeError: fetch failed] getaddrinfo EAI_AGAIN classifier.dev

Pointing it at a stand-in showed exactly what goes out — three briefs produced four requests:

{"items": ["custom cursor that follows the mouse with a trailing effect"],
 "dimensions": {"category": {"labels": ["hero","navigation","card", … ,"none of these"],
                             "instructions": "Classify this UI component into …"}},
 "tier": …}

Your brief text and the dimension definitions. The component index stays local.

Two things worth knowing about that. First, classifier.dev is not TypeSafe: the README describes it as “a free, keyless classification endpoint backed by TypeSafe’s Jev decision model”, so your brief passes through a third party on its way. Same shape as typesafe.pro, reviewed the same day. Second, the demo prints decisions spent: 7 — it counts its own calls, which is a small thing more projects should do.

A design note in classify.ts is worth repeating, because it is the kind of constraint most projects would hide: classifier.dev’s HTTP surface only returns label, confidence and per-label scores, with no native noul. So noul questions are encoded as two-label choices and scores["yes"] is used as the probability. Stated plainly, in a comment, next to the code that does it.

The limitations section is the review

Most projects’ “Limitations” is a shrug. This one opens with a registry it removed:

shadcnblocks is not indexed, despite being tagged. A real per-item availability check (does npx shadcn add actually work unauthenticated, not just what the index claims) found roughly half of its components return 401/403 “License required” at their real install URL, something invisible in the registry’s own index data.

And then it explains what happened to the check itself: shadcn-dashboard had the same problem at 32.5% and was fixed by filtering; shadcnblocks’ own full-scale check “got contaminated by the vendor’s rate limiter partway through before a clean filter could be produced, so it was pulled entirely rather than shipped unfiltered or filtered against bad data”.

Pulling a registry you have already paid to tag, because your verification run was contaminated and you will not ship results from bad data, is the behaviour this directory exists to find. The tagged data is kept, and the registry is expected back once a clean check runs.

It also names its own weakest signal — visual_density — and says a confidence-weighted matcher discounts weak tags automatically, rather than letting the average hide it.

One thing that is missing

Five source files point at a design-decisions document that is not in the repository:

src/runtime/match.ts:1      // See docs/DECISIONS.md #15 for why …
src/runtime/classify.ts:2   // See docs/DECISIONS.md #13 for why noul dimensions are sent as …
src/runtime/pick.ts:29      // docs/DECISIONS.md for the bug this replaced and how it was verified
src/runtime/types.ts:42     // … see docs/DECISIONS.md #7 and #11
src/runtime/registries.ts   // See docs/DECISIONS.md #6.

There is no docs/ directory, and git log --all -- docs/ returns nothing — it has never been committed. The comments cite numbered decisions with real substance (“the bug this replaced and how it was verified”), so the document evidently exists in the author’s workflow. Publishing it would turn five dangling references into the most interesting file in the repository.

Engineering

MIT, TypeScript, an MCP server plus a demo entry point. tsc --noEmit is clean; there are no tests, which for a matcher with a distance function and a confidence-weighted ranker is the gap to notice. Fifty stars.

Verdict

A genuinely useful shape — tag once, commit the tags, classify only the query — and an unusually honest account of what it could not verify.

Install it if you work across shadcn registries. Know that your brief text reaches a third-party endpoint on the way to Jev, and that the index you are matching against is only as good as the availability checks described in Limitations, which the author is refreshingly clear were not all clean.

For another free keyless front door to Jev, see typesafe.pro; for what a published decisions log looks like when it does ship, evoke.

See how it compares with other tools in Best Jev tools, tested hands-on.

Review updated Sep 22, 2026. Numbers quoted from the project are its author's own; we don't publish our own measurements of Jev.

More in Coding Agents & Developer Tools

fast-jev-compaction

★ 7.8k▲ 59

tamaratran/fast-jev-compaction

Claude Code plugin that replaces the compaction summary with Jev decisions. Every tool call and result is scored; stale ones are dropped or truncated, and everything kept stays verbatim.

TypeScriptReviewed

Foreman

★ 804▲ 17

thruwire/foreman

Puts Jev as a fast supervisor above slower coding agents such as Codex, starting from a ticket, spec, or bug report.

PythonReviewed

Jev Review

★ 695▲ 4

devagrawal09/jev-review

Staged code-review workflow for JavaScript and TypeScript with a local dashboard. Jev screens correctness, security, reliability, compatibility, and test risk, then scores severity and suggests a reviewer, with no generative model involved.

TypeScriptReviewed

Get new Jev projects every week

New Jev releases, pricing changes, and the best new projects, once a week. No spam; unsubscribe anytime.

Powered by Buttondown. See our privacy policy.