MCP Server

What it serves

The payload is generated from this repo — component sources, the notes and examples on every component page, and preset.ts — and bundled into the package, so it works in any project without access to this repo.

Setup

This is a private package, so set up registry auth first — see Installation for the two npmrc entries. Skipping it is worth avoiding here in particular: the install fails with a 401 that most MCP clients swallow, so the server just goes quietly missing rather than reporting an error.

Then install it as a dev dependency in the project your agent works in:

npm install -D @jgastager/bundy-ui-mcp

Then point your client at it. It speaks MCP over stdio — no server to run, no network access, no configuration beyond this:

{
  "mcpServers": {
    "bundy-ui": {
      "command": "npx",
      "args": ["-y", "@jgastager/bundy-ui-mcp"]
    }
  }
}

Tools

Ten tools, described so an agent picks the right one without being told to.

The validator

Most Bundy UI mistakes don't throw. An icon name that doesn't exist resolves to nothing and renders blank; an invalid variant falls through to an undefined class lookup; a <template #actions> on a component with no such slot silently drops its content. None of that surfaces as an error — it just quietly doesn't work.

validate_usage catches all of it statically, before the code is ever run:

<UiButton variant="glass" colour="primary" icon="sparkless">
  Go
</UiButton>

3 error(s), 0 warning(s). This markup will not work as written.

❌ line 1, <UiButton> — "glass" isn't a valid Button.variant.
   ↳ Allowed: "solid" | "subtle" | "soft" | "ghost".
❌ line 1, <UiButton> — <UiButton> has no prop "colour".
   ↳ Did you mean "color"?
❌ line 1, <UiButton> — "sparkless" isn't a bundled icon — icons
   resolve by name at runtime and a miss renders nothing.
   ↳ Did you mean "sparkles"?

It checks unknown components, misspelled props, invalid enum values, missing required props, unknown slot and event names, unbundled icon names, one-way v-model bindings, and overlays given both open and defaultOpen . Anything it can't resolve statically — a bound expression, a v-bind spread — is skipped rather than guessed at, so a clean result means something.

The same validator runs at build time over every recipe the server ships, so a composition can't drift from the component API without the build saying so.

Resources & prompts

Beyond tools, the same knowledge is addressable as MCP resources — useful for attaching a component's docs to a conversation directly:

And three prompts, each encoding the tool sequence that produces correct code so the discipline doesn't depend on the agent remembering it:

Keeping it current

The server reads a generated payload, not the live source. After changing a component, an example, a note, or the preset, regenerate it — the same npm run data that rebuilds this site's data:

npm run data       # docs data + package manifest + MCP payload
npm run data:mcp   # just the MCP payload

Set BUNDY_UI_MCP_DATA to a directory holding a freshly generated bundy-ui.json to serve a working tree instead of the bundled snapshot. To verify the server itself:

npm run mcp:test   # spawns the server, exercises every tool over real JSON-RPC

Without MCP

Agents that can't speak MCP still get a usable fallback: the package ships component-docs.json (every component's props, events and slots) and an AGENTS.md next to it, both readable straight out of node_modules .

import components from "@jgastager/bundy-ui/component-docs.json";

const button = components.find((c) => c.name === "Button");

It's the same component data, without the examples, tokens, guides, recipes or validation.