Generative UI MCP
Provides structured guidelines, canvas setup patterns, and interactive data controls for generating data visualizations using Chart.js.
Provides core design system rules and semantic color palette usage via CSS variables for consistent styling of generated UI components.
Provides setup guides, viewBox calculations, and layout rules for generating SVG illustrations, flowcharts, and diagrams.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type
@followed by the MCP server name and your instructions, e.g., "@Generative UI MCPvisualize my monthly sales data with an interactive chart"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Generative UI MCP
An MCP server that teaches AI models to generate interactive visualizations — charts, diagrams, mockups, and more.
Inspired by Anthropic's Artifacts and Vercel's Generative UI. This server provides structured design guidelines so AI models produce consistent, streaming-safe, visually polished widgets.
What it does
Instead of stuffing thousands of tokens of design rules into every system prompt, this MCP server lets the model load guidelines on demand — only when it actually needs to generate a visualization.
Module | What it covers |
| HTML controls, forms, sliders, calculators |
| Chart.js patterns, canvas setup, interactive data controls |
| UI mockup layouts, component patterns |
| SVG illustrations, artistic visualizations |
| Flowcharts, timelines, hierarchies, cycle diagrams, matrices |
The model calls load_ui_guidelines with the modules it needs, and gets back comprehensive design specs including:
Core design system (philosophy, streaming rules, CSS variables)
Color palette (6 ramps with semantic usage rules)
Component patterns and code templates
SVG setup guides with arrow markers and viewBox calculations
8 diagram types with layout rules and code examples
Related MCP server: mcpsystem.design MCP Server
Quick start
Auto-install via AI
Copy and paste the following prompt into your AI assistant (Claude Code, Cursor, etc.) to install automatically:
Install the
generative-ui-mcpMCP server. Runnpx generative-ui-mcpas a stdio MCP server. The server name should be "generative-ui".
Claude Code
claude mcp add generative-ui -- npx generative-ui-mcpClaude Desktop
Add to your claude_desktop_config.json:
{
"mcpServers": {
"generative-ui": {
"command": "npx",
"args": ["generative-ui-mcp"]
}
}
}Cursor / Windsurf
Add to your MCP settings (.cursor/mcp.json or equivalent):
{
"mcpServers": {
"generative-ui": {
"command": "npx",
"args": ["generative-ui-mcp"]
}
}
}Tool
load_ui_guidelines
Load detailed design guidelines for generating visual widgets.
Parameters:
Name | Type | Description |
|
| Modules to load: |
Example call:
{
"name": "load_ui_guidelines",
"arguments": {
"modules": ["chart", "diagram"]
}
}Shared sections (like Core Design System and Color Palette) are automatically deduplicated when loading multiple modules.
Resource
generative-ui://system-prompt
A compact system prompt snippet (~300 tokens) with all hard constraints needed for valid widget output. Hosts can inject this into their system prompt so the model can generate basic widgets even without calling the tool.
Contains: output format, JSON escaping rules, streaming order, CDN allowlist, SVG setup, size limits, and interaction patterns.
How it works
┌─────────────┐ system prompt ┌─────────────┐
│ AI Host │ ◄── injects ──────── │ Resource: │
│ (Claude, │ ~300 tokens │ system-prompt│
│ Cursor, │ └─────────────┘
│ etc.) │
│ │ tool call ┌─────────────┐
│ Model ────│──► load_ui_ │ Guidelines │
│ │ guidelines │ Modules │
│ │ ◄── returns ──────── │ (on demand) │
│ │ detailed specs └─────────────┘
└─────────────┘Token savings: The system prompt is ~300 tokens vs ~650+ tokens for full guidelines. Detailed specs are only loaded when the model actually needs to generate a visualization. Most conversations don't involve widgets, so this saves tokens on every request.
Development
npm install
npm run build
npm startLicense
MIT
Available Tools
1 toolload_ui_guidelinesA
Load detailed design guidelines for generating visual widgets. Call this before generating your first widget in a conversation. Available modules: interactive, chart, mockup, art, diagram.
| Name | Required | Description | Default |
|---|---|---|---|
| modules | Yes | Which guideline modules to load. interactive = HTML controls/forms, chart = Chart.js, mockup = UI mockups, art = SVG illustrations, diagram = flowcharts/timelines/hierarchies. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclosure behavioral traits. However, it does not explain what happens when guidelines are loaded (e.g., caching, return value, side effects on conversation state). The agent is left unclear about the tool's impact beyond the fact that it loads guidelines.
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 two sentences long with no wasted words. It front-loads the primary action and includes necessary context and module listing. Every sentence contributes meaning.
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?
For a simple tool with one parameter and no output schema, the description covers when to use and what modules are available. However, it lacks details on what the guidelines contain or how they affect subsequent widget generation, leaving room for ambiguity.
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 the parameter is fully documented in the schema. The description adds no additional meaning beyond listing the available modules, which is already present in the schema. Thus, the description provides no extra value for parameters beyond 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?
The description clearly states that the tool loads design guidelines for generating visual widgets, with a specific verb and resource. It also provides context by recommending to call it before the first widget, making the purpose unambiguous even without siblings.
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?
The description explicitly instructs to call this tool before generating the first widget, providing clear when-to-use guidance. It does not mention when not to use it, but with no sibling tools, this is sufficient for most cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
1 tool update
v1.0.0- First observed
load_ui_guidelines
TDQS
Scored across 1 tool
With only one tool, there is no possibility of ambiguity or overlap between tools. The single tool has a clear, distinct purpose of loading design guidelines for UI generation.
The single tool name follows a clear verb_noun pattern (load_ui_guidelines), and with only one tool, consistency is inherently perfect as there are no other names to compare against.
One tool is too few for a server named 'Generative UI MCP', which suggests a broader scope of generating visual widgets. The tool only loads guidelines, lacking actual generation, editing, or management tools, making the set feel incomplete and thin for the implied purpose.
The server is severely incomplete for generative UI tasks. It only provides guidelines loading, with no tools for creating, updating, deleting, or rendering widgets, leaving significant gaps that will cause agent failures in generating visual content.
Maintenance
Related MCP Connectors
A design-style library for AI agents: search real styles, fetch a ready-to-apply design spec.
UI design from prompts, screenshots, and URLs for AI coding agents and theme tokens.
Serves your design system and coding standards to coding agents, so they stop guessing.
Live React design-system APIs, patterns, and code validation so AI agents build real UI, not slop.
Related MCP Servers
- FlicenseBqualityDmaintenanceProvides AI tools with access to Visa's Product Design System resources, including design tokens, component specifications, and usage guidelines.11-
- AlicenseNot gradedqualityDmaintenanceProvides AI assistants with access to a production-ready design system including Tailwind CSS component patterns, style guides (colors, typography, spacing), and Web Components specifications for consistent UI development.5 npmMIT
- AlicenseAqualityAmaintenanceProvides deterministic design style recommendations and structured tokens for AI content generation, with 30 curated styles including color palettes, typography, and visual directives.211 npmMIT
- AlicenseAqualityBmaintenanceProvides deterministic, read-only design knowledge for AI coding agents to help them choose visual directions, plan UI states, and compose design tokens, all without network access.612 npm4MIT