The labsUI MCP server helps coding agents discover, inspect, install, configure, compare, update, and validate labsUI components in a project.
Search components, blocks, hooks, helpers, and setup items by name, export, or intent; filter by kind and limit; empty query lists everything.
View exact props, types, usage, examples, included files, dependencies, and npm packages before writing code.
Add items and everything they import into the project, including npm packages, with optional dry-run and existing-file preservation.
Init one-time setup for styles, theme, utils, and motion provider; writes labsui.json and returns root layout code.
Diff installed items against the current labsUI registry version.
Update installed items with three-way merging, conflict markers for overlapping edits, and optional dry-run.
Doctor checks React 19, Tailwind v4, path alias, stylesheet import, provider/theme wiring, mounted Toaster/Confirmer, missing packages/files, and local edits, with fixes.
Clean, composable React components with one smooth spring for every motion. Hand-made, accessible, and copied into your project so you own the code.
Docs and live demos · npm · JSR · MCP registry · Glama
One spring. Every animation shares
{ type: "spring", stiffness: 400, damping: 30 }, so the whole UI moves the
same way. Reduced motion is respected everywhere.
You own the code. npx @kznlabs/labsui add writes plain TSX into your
repo. No runtime package to upgrade around, edit anything.
Accessible by default. WAI-ARIA patterns, full keyboard support, and WCAG AA contrast in light and dark mode for all eight accent colors.
Server-friendly. Many components are server-safe, and form controls use native validation, so forms work without JavaScript and with Server Actions.
80+ components and blocks. Inputs, overlays, navigation, data display, charts, motion helpers, and ready-made blocks like pricing, site header and changelog.
Related MCP server: Next.js DevTools MCP
CI runs an automated sweep on pull requests (the pages a change reaches) and
daily (everything): all component pages, light and dark, at 390 px and
1280 px, in three browser engines. The badges show the latest full run on
main.
Check | Required |
WCAG 2.2 A + AA rules (axe) | 0 violations |
JavaScript errors | none |
Sideways page overflow | none |
Every control reachable by a click | pass |
Scroll containers move under the wheel | pass |
Menus, popovers, tabs, sliders, Escape, focus | pass |
Pointer targets | 24 × 24 px or larger |
Text contrast, both themes | 4.5:1 or higher |
Engine | Covers | Status |
Chromium | Chrome, Edge, Brave, Opera, Opera GX | |
Gecko | Firefox | |
WebKit | Safari (macOS); iOS shares the engine |
Minimum versions come from Tailwind CSS v4: Chrome 111, Safari 16.4,
Firefox 128. Two features enhance where supported and fall back cleanly:
styled select popups (appearance: base-select, Chromium and newer Safari;
elsewhere the native list) and auto-growing textareas (field-sizing; a
resize handle in Firefox).
Automated checks find many problems, not all: axe covers roughly half of the WCAG criteria, so this is not a full conformance audit. Not yet covered: screen reader passes, real phones (iOS Safari, Android Chrome), Samsung Internet and other less common browsers.
Requires React 19, Tailwind CSS v4 and a @/* path alias in tsconfig.json.
The CLI runs on Node.js 22 or newer, or Deno.
npx @kznlabs/labsui init # styles, theme, utils, motion provider
npx @kznlabs/labsui add button dialog # components plus everything they import
npx @kznlabs/labsui search date range # find by name, export or intent
npx @kznlabs/labsui view dialog # exact props, examples, what it installs
npx @kznlabs/labsui doctor # check the setup, with a fix for each problemAny package manager works: bunx, pnpm dlx, yarn dlx and
deno run -A jsr:@kznlabs/labsui too, and npm packages install with whichever
one your lockfile shows. Bun is recommended: labsUI is built with it.
See the CLI reference for every option.
Coding agents get the same through npx @kznlabs/labsui mcp, an MCP server
with search, view, add, init, diff, update and doctor tools plus the
library's coding rules, or through --json on any command. It's listed in the
MCP registry as io.github.kznlabs/labsui and on
Glama:
{
"mcpServers": {
"labsui": { "command": "npx", "args": ["-y", "@kznlabs/labsui", "mcp"] }
}
}import { Button } from "@/components/ui/button";
export function DeleteButton({ onDelete }: { onDelete: () => void }) {
return (
<Button variant="destructive" confirmLabel="Yes, delete" onClick={onDelete}>
Delete
</Button>
);
}Group | Examples |
Actions & inputs | Button, Field, Select, Combobox, Date picker, Slider, OTP, Tag input |
Overlays & feedback | Dialog, Drawer, Popover, Dropdown and context menus, Command palette, Toast |
Navigation | Tabs, Sidebar, Menubar, Navigation menu, Breadcrumb, Pagination |
Data display | Table, Data table, Chart, Carousel, Timeline, Code, Terminal |
Layout | Card, Accordion, App window, Resizable panels, Scroll area |
Motion | Reveal, Count to, Typewriter, Text swap, Custom cursor |
Blocks | Pricing, Site header, Stats strip, Product card, Changelog, Newsletter |
Theming is built on OKLCH tokens with light and dark mode and eight accent
presets, or your own hue through --accent-hue.
labsUI is built with Bun, and the repo scripts run on it, so install Bun to work on the library itself.
bun install
bun dev # docs site with every component
bun run lint # Biome
bun run typecheck # also rebuilds the registry and API docs
bun run check-dead-code # Knip
bun test # unit tests for helpers and the CLI
bunx markdownlint-cli2 # MarkdownThe docs site deploys from main to GitHub Pages. A cli-v<version> tag
publishes the CLI to npm and JSR.
Install labsUI items into the project: copies each item and everything it imports, then installs their npm packages. Existing files are kept, never overwritten. Returns the files written, the packages installed and anything to mount once in the root layout. Needs init first; dryRun previews. To bring installed items to a newer version, use update instead.
| Name | Required | Description | Default |
|---|---|---|---|
| names | Yes | Item names as search lists them, e.g. button or date-picker. | |
| dryRun | No | Report what would change, write nothing. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (non-read-only, idempotent, non-destructive, open-world), the description discloses the conflict policy ('Existing files are kept, never overwritten'), a side effect the annotations don't convey (npm package installation, consistent with openWorldHint), and what is returned. This is the behavioral context an agent needs before running an installer.
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 tight sentences ordered by importance: what it does, what it will not do, what it returns, then prerequisites and the alternative. No filler and nothing buried.
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?
Although there is no output schema, the description names the return payload (files written, packages installed, root-layout mount instructions). Combined with prerequisites and the sibling routing, an agent has everything needed to call this correctly.
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 both parameters are already documented, including the 'as search lists them' naming convention and dryRun's write-nothing semantics. The description only restates dryRun as a preview, adding no syntax or format detail beyond the schema — baseline 3.
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?
States a specific verb and resource ('Install labsUI items into the project') and then spells out the mechanism — copying each item plus its imports and installing npm packages. This is clearly distinguishable from sibling tools like update, search, and view.
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?
Gives explicit prerequisites ('Needs init first'), an in-tool alternative mode ('dryRun previews'), and a named sibling for a different intent ('To bring installed items to a newer version, use update instead'). The when-to-use routing is complete.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Compare installed labsUI items with this labsUI version. Returns a unified patch per changed file, from the registry file to the project file (+ lines exist only in the project); matching items are left out, and when nothing differs it says so. Use it to see local edits before update. Needs init.
| Name | Required | Description | Default |
|---|---|---|---|
| names | No | Installed item names, e.g. button. Empty: all installed items. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds substantial context beyond the readOnly/openWorld annotations: it explains the return is a unified patch per changed file, defines the diff direction ("from the registry file to the project file; + lines exist only in the project"), notes that matching items are omitted, and says what happens on no differences. It also states the init prerequisite.
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?
Four short sentences, each doing distinct work: what it compares, what it emits, how to read the output, and when to use it. Front-loaded with the core comparison and no filler.
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?
With no output schema, the description compensates by describing the return format and direction explicitly, and it covers the prerequisite. An agent has everything needed to call this and interpret the result.
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 a single documented `names` parameter including pattern, maxItems, and the empty-array behavior, so the schema carries the burden. The description says nothing about the parameter, so the baseline 3 applies.
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?
States a specific verb and resource ("compare installed labsUI items with this labsUI version") and pins down the output direction. It is clearly distinguishable from siblings like `update`, `view`, and `search`, which do not produce a patch.
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?
"Use it to see local edits before update" gives a concrete situation and implicitly positions `update` as the follow-up action, and "Needs init" flags the prerequisite. It stops short of explicitly naming an alternative for the case where you want to inspect a single item rather than a diff (e.g. `view`).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check the labsUI setup: React 19, Tailwind v4, the path alias, the stylesheet import, MotionProvider and themeScript wiring, mounted Toaster/Confirmer, missing npm packages or files, and local edits. Returns pass, warn or fail per check, each problem with its fix. Run it after init or add, or when components look unstyled; for line-level changes use diff.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already establish that this is a read-only, closed-world operation. The description adds valuable behavioral detail by saying it returns pass, warn, or fail per check and includes fixes for each problem, though it does not further discuss performance or permissions.
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 front-loaded with the purpose, then lists the concrete checks, then states the return shape and usage guidance. Every sentence contributes to selecting or interpreting the 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?
With no input parameters and no output schema, the description carries the full burden and does so well: it covers what is checked, what the result states mean, that fixes are included, and when to use the 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?
The tool takes zero parameters, so there is no parameter semantics to explain. The baseline score for a zero-parameter tool is appropriate here.
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 gives a specific verb and resource: it checks the labsUI setup and enumerates exactly what is inspected, including React 19, Tailwind v4, aliases, providers, Toaster/Confirmer, packages, files, and local edits. It also distinguishes itself from the sibling diff tool for line-level changes.
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?
It explicitly states when to run the tool: after init or add, or when components look unstyled. It also points to the alternative sibling diff for line-level changes, leaving little ambiguity about when this tool is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Set up labsUI in a project, once, before add: writes the styles, theme, utils and motion provider, imports labsui.css into the Tailwind stylesheet and records settings in labsui.json. Returns warnings, the files written and the root layout code to add. Needs React 19 and Tailwind v4; run doctor first if unsure. Safe to repeat: existing files are kept. dryRun previews.
| Name | Required | Description | Default |
|---|---|---|---|
| dryRun | No | Report what would change, write nothing. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations, the description discloses the concrete artifacts written, that existing files are preserved on re-run (a stronger statement than idempotentHint), the prerequisite stack (React 19, Tailwind v4), and the return payload (warnings, files written, root layout code to add). No mutation of user files is hidden from the agent.
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?
Roughly three sentences with no filler: what it writes, what it returns, prerequisites, and repeat/preview behavior in that order. The critical 'once, before add' constraint is front-loaded in the first clause.
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?
Even with no output schema, the description names what comes back (warnings, files written, root layout code). Combined with prerequisites and idempotency behavior, an agent has everything needed to decide whether and how to call it.
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?
With only one parameter at 100% schema coverage the schema already defines dryRun fully. The description's 'dryRun previews' reinforces the intent in the context of this specific tool, but adds little beyond the schema's 'Report what would change, write nothing.'
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?
States the specific action (scaffold labsUI into a project) and enumerates exactly what it produces: styles, theme, utils, motion provider, a labsui.css import in the Tailwind stylesheet, and a labsui.json settings file. It also positions itself relative to siblings by saying it runs 'once, before add', so an agent can separate it from add, doctor, and update without opening any schema.
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?
Gives explicit ordering ('once, before add'), a fallback path ('run doctor first if unsure'), and a preview option ('dryRun previews'). The 'safe to repeat' clause tells the agent it need not guard against re-invocation, which is exactly the decision point an agent faces with a setup tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find labsUI components, blocks, hooks and helpers by name, export (useModal) or intent (date range, toast promise). All words must match, best match first; no query lists everything. Returns one line per hit: name, kind and summary. Start here when you don't know an item's name, then call view on the hits.
| Name | Required | Description | Default |
|---|---|---|---|
| kind | No | Only this kind: component (primitive), block (composed section), hook, helper or setup. | |
| limit | No | Most results to return. | |
| query | No | Words to match. Empty lists everything. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnlyHint=true, openWorldHint=false), and the description adds matching semantics ('All words must match, best match first') plus a return shape ('one line per hit: name, kind and summary'). It stops short of noting truncation behavior or how to widen a too-narrow match, but the added context is solid.
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 short sentences, front-loaded with purpose, then matching rules, then return shape and the next-step routing. No filler or restatement of the title.
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?
With no output schema, the description carries the return-format burden and does so ('one line per hit: name, kind and summary'). Combined with annotations and full schema coverage, an agent has everything needed to call this and act on 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?
Schema coverage is 100%, so the baseline is 3; the description earns extra by explaining matching behavior for query (all words must match, best-first ordering, empty lists everything) and by noting exports are searchable targets. It adds no detail on kind or limit beyond the enum and bounds already in the schema.
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?
States a specific verb and resource ('Find labsUI components, blocks, hooks and helpers') and enumerates the three matchable facets: name, export, and intent. This is clearly distinguishable from siblings like view, add, or update without opening any schema.
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 'Start here when you don't know an item's name, then call view on the hits,' naming the alternative and the condition that selects it. Also covers the degenerate case: 'no query lists everything.'
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Bring installed labsUI items to this labsUI version. Unedited files are replaced; edited ones are merged three ways from the version that installed them, with conflict markers where both sides changed the same lines. Returns each changed item as replaced, merged, conflicts (with the files to resolve) or kept with the reason. Run diff first to see local edits; dryRun previews. Only for installed items: new ones go through add.
| Name | Required | Description | Default |
|---|---|---|---|
| names | No | Installed item names, e.g. button. Empty: all installed items. | |
| dryRun | No | Report what would change, write nothing. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations, it discloses the actual mutation semantics: unedited files are replaced, edited files are three-way merged from the installing version, conflict markers appear when both sides change the same lines, and each item returns as replaced, merged, conflicts, or kept with a reason. This is exactly the kind of destructive-behavior context the annotations alone do not provide.
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 compact and front-loaded: purpose first, then replacement/merge behavior, return categories, inspection alternatives, and scope restriction. Every sentence carries useful information.
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?
With no output schema, the description still explains the return categories (replaced, merged, conflicts with files to resolve, kept with reason) and the preview path (dryRun, diff). For a destructive update tool, this gives the agent enough to call and interpret it correctly.
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 and their defaults. The description reinforces dryRun as a preview mode but adds no syntax or format detail beyond the schema, so baseline 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?
The description states a specific action ('Bring installed labsUI items to this labsUI version') with a clear scope (installed items) and explicitly separates itself from 'add' for new items and 'diff' for inspection. An agent can distinguish this from siblings without opening schemas.
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?
It names the alternative tools and the conditions that select them: 'Run diff first to see local edits; dryRun previews' and 'Only for installed items: new ones go through add.' This is explicit when-to-use and when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read the docs of labsUI items by name: exact props and types, a usage line, full examples, and the items and npm packages each brings along. Call it before writing code with a component instead of guessing props; find names with search, install with add.
| Name | Required | Description | Default |
|---|---|---|---|
| names | Yes | Item names as search lists them, e.g. button or date-picker. | |
| source | No | Include the source files. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=false, so safety is covered; the description adds real value by disclosing what the read returns (props/types, usage line, examples, bundled packages). It stops short of saying what happens for unknown names or whether lookups are cached/batched, so not a 5.
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, zero filler, with the core action and payload front-loaded before the workflow guidance. Every clause 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?
No output schema exists, so the description carries the return-value burden and does so by listing the exact contents of the response. Combined with the sibling routing and annotation coverage, an agent has everything needed to call it correctly.
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 description coverage is 100%, so both parameters (names, source) are already documented in the schema. The description only reinforces that names are the lookup key ('by name') and does not mention the source flag at all, so it adds little beyond the schema — baseline 3.
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?
States a specific verb and resource ('Read the docs of labsUI items by name') and enumerates the payload: exact props and types, a usage line, full examples, and the items and npm packages each brings along. An agent can distinguish this from search/add without opening any schema.
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?
Explicit directive: 'Call it before writing code with a component instead of guessing props', plus routing for the neighbouring steps — 'find names with search, install with add'. Both the when-to-use and the alternatives are named.
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.5diff1 field changedInput schema / properties / names / descriptionPrevious value: -"Installed item names, e.g. button. Empty: every installed item."New value: +"Installed item names, e.g. button. Empty: all installed items."search1 field changedInput schema / properties / kind / descriptionPrevious value: -"Only items of this kind."New value: +"Only this kind: component (primitive), block (composed section), hook, helper or setup."update1 field changedInput schema / properties / names / descriptionPrevious value: -"Installed item names, e.g. button. Empty: every installed item."New value: +"Installed item names, e.g. button. Empty: all installed items."v0.1.4add2 fields changedInput schema / properties / dryRun / descriptionPrevious value: -"Report, write nothing."New value: +"Report what would change, write nothing."Input schema / properties / names / descriptionAdded value: +"Item names as search lists them, e.g. button or date-picker."diff1 field changedInput schema / properties / names / descriptionAdded value: +"Installed item names, e.g. button. Empty: every installed item."init1 field changedInput schema / properties / dryRun / descriptionAdded value: +"Report what would change, write nothing."search2 fields changedInput schema / properties / kind / descriptionAdded value: +"Only items of this kind."Input schema / properties / limit / descriptionAdded value: +"Most results to return."update2 fields changedInput schema / properties / dryRun / descriptionPrevious value: -"Report, write nothing."New value: +"Report what would change, write nothing."Input schema / properties / names / descriptionAdded value: +"Installed item names, e.g. button. Empty: every installed item."view1 field changedInput schema / properties / names / descriptionAdded value: +"Item names as search lists them, e.g. button or date-picker."v0.1.3adddiffdoctorinitsearchupdateviewScored across 7 tools
Each tool owns a distinct phase of the workflow: init sets up, add installs, update upgrades, diff compares, doctor diagnoses, search finds names, view reads docs. Descriptions explicitly disambiguate the close pairs (search vs view, add vs update, diff vs update), so misselection is unlikely.
All names are single lowercase words with no style mixing, which is easy to read and predict. The only wrinkle is that the set blends verbs (add, view, search) with nouns/abbreviations (doctor, diff, init), so the grammar isn't uniformly verb-based.
Seven tools is right-sized for a component registry: init, add, search, view, update, diff, doctor each map to a real step in the setup/install/upgrade cycle. No tool feels redundant or like padding.
The lifecycle from init through add, diff, update and doctor is well covered, with search and view supporting discovery and usage. The notable gap is any remove/uninstall or list-installed operation, leaving cleanup and inventory as dead ends an agent must handle manually.
React + Tailwind UI components and recipes your AI coding tool can search and install.
Search, view and install React + Tailwind CSS components and landing pages from UpFork.
Search, read and install agent-ready React components, screens and blocks for AI products.
Search shadcn registry items, read props and get exact install commands for React components.
