The questions a component library should be able to answer with a path.

A library of 33 interface components, 15 worked screens and 6 complete page templates, written as plain HTML, CSS and JavaScript against one shared design-token stylesheet. Every one of the 33 components is also ported to React, Vue and Web Components, and each carries a machine-readable MUE:META contract — variants, props, accessibility notes, keyboard behaviour, events, licence and a dated verification note — so a human can read it and a coding agent can retrieve it instead of generating generic markup.

Sources: README.md, showcase/data/component-catalog.json, frameworks/registry.json.

No. The engine is static files: copy design-tokens/engine.css and styles/components.css into your project, then take the markup from the component you want. Nothing imports a package, nothing calls a CDN, and no preview on this site makes a single remote request. The React, Vue and Web Components ports are for apps that already use those frameworks — the framework is not a requirement of the design system.

There is no npm package. You copy the folder, the same way shadcn/ui-style kits hand you source instead of a dependency.

It overlaps in spirit — you own the code after you take it — and differs in mechanism. shadcn/ui pastes React components built on Radix primitives and styled with Tailwind utility classes. This kit is HTML/CSS/JS first, styled with semantic classes off one token file, and the React, Vue and Web Components ports write the same classes rather than a Tailwind config. No code is vendored from shadcn/ui, Ant Design, Nuxt UI, daisyUI or Flowbite; the token naming convention is borrowed from shadcn/ui and the rest is this repository’s own work, which RESOURCES.md documents library by library with licences.

Tokens are the named decisions a design system repeats: colour ramps, spacing, radii, shadows, type scale, motion durations. Here they are CSS custom properties in design-tokens/engine.css, and styles/components.css — 404 classes, maintained by hand and checked by tools/audit/check-classes.js — consumes them instead of hardcoding values. That is why light and dark are one file apart, and why a component ported to Vue looks identical to the vanilla original: the three stacks write the same classes and ship no CSS of their own.

Try it live at /engine/showcase/studio.html — the token studio recomputes ramps and reports WCAG contrast as you drag.

Keyboard paths and ARIA wiring are part of the contract, not decoration: dialogs trap focus and return it on Escape, tabs use a roving tabindex with arrow and End keys, switches toggle on Space, accordions keep one panel open, sortable tables write aria-sort, and error states set aria-invalid. Contrast is audited for WCAG AA in light and dark across four widths, and axe-core reports zero serious or critical findings in the 24 framework runs recorded for 2026-11-01.

The gap: no run has used a screen reader or a touch device, so “announced correctly in NVDA/VoiceOver” is not a claim this repository makes. Each component’s A11Y and KEYBOARD fields list what was checked.

Three commands, no install: node tools/audit/framework-parity.mjs (registry, classes, licences and verification notes), node tools/mue.js check all (unresolved classes and missing metadata across 54 previews), and node site/build.mjs to reproduce the deployed copy. The behaviour harness and axe-core runs live outside the repo because they need a browser binary — docs/framework-support.md records exactly which commands produced each number.

React (34 modules), Vue (37 single-file components) and Web Components (40 modules defining 43 <mue-*> tags) each cover all 33 catalogued components. Run node tools/mue.js stack for the counts as the repository sees them: react: 33/54 entries live, the same for vue and web-components, and svelte: 0/54 entries live, 33 documented as planned.

So a component cannot drift between stacks. The React Card, the Vue MueCard and the <mue-card> element all write card, card-header and the same variant classes; the parity audit reads every class a binding writes and fails if it is not defined in the shared layer. Web Components are light DOM on purpose — the gallery reports 0 shadow roots — so the same document-level tokens apply.

Svelte and Angular have written plans and no code, and no date is promised. Next.js-specific work is not planned: the ports are plain client components, and server rendering has never been run here, so nothing labels itself Next-ready. Ask the CLI rather than trusting a badge — node tools/mue.js show ui-cards --framework svelte answers “This repository has no svelte component for ui-cards” and points at the plan.

Three surfaces, in the order an agent usually needs them: AGENTS.md and SKILL.md for the instruction layer, node tools/mue.js for retrieval (search, show, add, stack, registry --json), and showcase/data/component-catalog.json when the agent would rather read one file than run a command. mue add ui-cards --framework react --into ./src writes the component plus the token and stylesheet layers it depends on, and rewrites the barrel so it only references what it installed.

No MCP server exists yet. The registry is the seam one would be built on; today any shell-capable agent can use the CLI without registration.

It removes the repetitive part. An agent that retrieves an audited dialog does not have to invent focus trapping again, and a small open model starts from something already checked rather than something improvised. It does not raise a model’s reasoning ceiling, it does not judge whether your content makes sense, and it does not remove testing in your project — mue check finds unresolved classes, not bad copy.

The public endpoints are the two the site itself uses: POST /api/track for a page view or event and POST /api/subscribe for the waitlist. Both refuse a request whose Origin is not the site’s own host, and both re-validate every field server-side. Everything else under /api/ and /admin is session-gated, and every one of those URLs carries a noindex signal, so none of them is offered to a search engine.