@xmcp-ui

[0xKoller]

New UI Package: @xmcp-dev/ui

We've introduced a new UI package @xmcp-dev/ui that sits closer to shadcn/ui in spirit than a low-level widget schema. It supports two complementary authoring modes that share the same visual foundation:

1. Direct React Authoring (Human-friendly)

Engineers can build UIs using familiar, package-owned components such as:
Card, Button, Input, Select, Table, Alert, Badge, Checkbox, Switch, Textarea, and layout primitives.

This provides a clean, shadcn-style developer experience.

2. Programmatic JSON Authoring (Agent-friendly)

Agents and tools can generate a JSON AppSchema, which is then rendered by the same runtime and component system. Both paths use the same component vocabulary and theming layer, ensuring visual consistency.

What Was Added

• Full renderer/runtime for schema-driven apps
• Schema validation (JSON is validated before rendering)
• Core types: App, AppSchema, ThemeProvider, ThemeTokens, etc.
• App-level theming hooks — branding can now be controlled via tokens instead of only per-component overrides
• className support for JSON-rendered components, enabling per-instance customization even in programmatic UIs

Demo / Showcase

We built a new ui-showcase example that demonstrates:

• Broad coverage of the component surface
• Focused sections for buttons, forms, selection controls, and data display
• Theming demo showing the same primitives under different app-level themes
• renderJson tool for rendering raw JSON App Schemas
• Copy-paste sample JSON file for easy testing

What This Proves

• Humans get a familiar, high-quality component library for building MCP App UIs
• Agents can generate UIs programmatically via JSON
• Both paths remain visually consistent thanks to a shared renderer and theme system

Future Considerations

1. Renderer Registry Architecture
   The current registry is simple and functional but manual. As the component set grows, we should move toward a declarative component-definition model where each component declares its schema shape, renderer binding, React primitive mapping, and metadata. This would reduce drift between validation, runtime, and documentation.

2. Stronger Renderer Contracts
   While the renderer is already cleaner, the binding layer could become loose over time. Long-term, we should make JSON-rendered component contracts more explicit and strictly typed.

3. Better Layer Separation
   Current structure (react/, components/, renderer/) is solid. We should enforce this separation more strictly so primitives stay pure and schema bindings remain thin.

4. More Forgiving LLM Input Path
   The current renderJson is quite strict. For better agent experience, we should consider:

   • A friendlier “basic UI” schema
   • Normalization and sensible defaults
   • Improved error handling / recovery

5. Slot-level Styling Overrides
   Currently customization is mostly top-level className + app-level tokens. In the future, we may want slot-level overrides (e.g. headerClassName, contentClassName, triggerClassName) especially for the JSON/programmatic path.

6. Theming Maturity
   The token system is a good foundation. Future improvements could include named presets, theme inheritance, per-app/per-section scoping, and clearer documentation of stable/public tokens.

7. Long-term Extensibility
   If external teams will build on top of this package, we need to decide whether extensions should happen via:

   • Registering custom schema components
   • Composing React primitives only
   • Or both
     This decision will significantly impact the registry and schema design.

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
xmcp-website	Error		Apr 13, 2026 3:04pm

[github-actions]

Rspack Bundle Analysis

Build	Assets	Total Size (MB)	Build Time
Main Compiler	4	6.35	5.31s
Runtime Compiler	6	5.38	5.95s

Main Compiler

Source: stats-main.json

Asset	Chunk	Size (KB)	Size (MB)
cli.js	cli	6036.22	5.89
index.js	index	368.80	0.36
cloudflare.js	cloudflare	81.70	0.08
detached-flush.js	detached-flush	15.18	0.01

Total emitted JS: 6.35 MB

Runtime Compiler

Source: stats-runtime.json

Asset	Chunk	Size (KB)	Size (MB)
http.js	http	1310.82	1.28
adapter-nestjs.js	adapter-nestjs	1287.09	1.26
adapter-nextjs.js	adapter-nextjs	1281.13	1.25
adapter-express.js	adapter-express	1279.40	1.25
stdio.js	stdio	348.46	0.34
headers.js	headers	1.33	0.00

Total emitted JS: 5.38 MB

Package Footprint (npm pack + npm install)

Item	Size (KB)	Size (MB)
Tarball (.tgz)	4639.36	4.53
dist/	12062.77	11.78
node_modules/	101301.97	98.93
dist + node_modules	113364.74	110.71