@wizeworks/silicaui-mcp 0.36.0 → 0.38.0

package/README.md

@@ -58,19 +58,55 @@ add to `.cursor/mcp.json`:
 No API key, account, or network access required after install — everything the
 server answers with is bundled in the package.
 
+## The three delivery paths
+
+Silica UI is one design system consumed three different ways, and the server
+tells every connecting client so up front (via MCP `instructions`, which clients
+surface before the first tool call) — because the choice is made *before* any
+tool gets called, and getting it wrong is the most common way an integration
+breaks.
+
+| Path | Package | You write | Interactive? |
+| --- | --- | --- | --- |
+| **CSS** | `@wizeworks/silicaui` | Plain HTML + classes: `<button class="btn btn-primary">` | No — no JS ships |
+| **React** | `@wizeworks/silicaui-react` | `<Button color="primary" size="lg">` | Yes, via Base UI |
+| **HTML / node-tree** | `@wizeworks/silicaui-html` + `@wizeworks/silicaui-behaviors` | A node tree that projects to HTML with `data-sui-*` markers | Yes, once the behaviors runtime loads |
+
+`get_component` answers on all three. Called without a `package`, it returns
+every path's shape side by side so an assistant can see how they differ rather
+than guessing which one it wants:
+
+```jsonc
+// get_component({ name: "Button" })
+{
+  "name": "button",
+  "note": "\"Button\" exists on 3 delivery paths … they are not interchangeable.",
+  "paths": [
+    { "package": "@wizeworks/silicaui",       "root": "btn", "classes": ["btn", "btn-outline", …], "colorVariants": ["btn-primary", …] },
+    { "package": "@wizeworks/silicaui-react", "props": [ … ], "usageExample": "…" },
+    { "package": "@wizeworks/silicaui-html",  "category": "content", "label": "Button", "container": false, "behaviors": [] }
+  ]
+}
+```
+
+Pass `package` to get just one.
+
 ## Tools
 
 | Tool | Purpose |
 | --- | --- |
 | `list_packages` | The Silica UI package family, purpose, install command, version. |
-| `list_components({ package? })` | Component names + categories, optionally filtered to one package. |
-| `get_component({ name })` | A component's real props (from source) + a real usage example (from the playground). |
+| `list_components({ package? })` | Component names + categories across all three paths, optionally filtered to one package. |
+| `get_component({ name, package? })` | A component's real shape on each path: CSS root class + classes + color variants, React props (from source) + a real usage example, or the `-html` macro and its behaviors. |
 | `list_classes({ component? })` | Exact, literal CSS class names — extracted from the actual class generators. |
 | `get_tokens()` | Semantic color list, light/dark values, typography tokens. |
 | `list_blocks({ category?, tag? })` | Composed page blocks (hero, FAQ, feature grid, …), summary only. |
 | `get_block({ key })` | One block's full node tree. |
 | `list_behaviors()` / `get_behavior({ type })` | The `data-sui-*` interactive-behavior contract. |
-| `search_docs({ query })` | Free-text search across components, blocks, and behaviors. |
+| `get_node_schema({ section? })` | Path 3's document schema (`@wizeworks/silicaui-html`): the four node kinds, the typed system-metadata band, the data-binding vocabulary, the host resolution contract, and the tag/attribute allowlist `toHtml` enforces. |
+| `list_email_nodes()` | The email builder's closed node schema (`@wizeworks/silicaui-builder/email`): every kind, what it may hold, what may hold it, the insertable presets, and the document envelope. |
+| `get_email_node({ kind })` | One email node kind's real typed fields (with source docs) and its data-binding contract — which `attr` a bind may target. |
+| `search_docs({ query })` | Free-text search across components, blocks, behaviors, classes, tokens, node-tree bindings and allowed tags, and email node kinds. |
 
 ## A note on versioning