Provides access to Ant Design, enabling selection and guidance for building enterprise-grade React interfaces with its components, patterns, and installation details.
Provides access to Ariakit, enabling selection and guidance for accessible React UI primitives and composable component patterns.
Provides access to Atlassian's design system, enabling selection and guidance for building polished, accessible enterprise product interfaces.
Provides access to Blueprint, enabling selection and guidance for data-dense, desktop-style React UI interfaces.
Provides access to Chakra UI, enabling selection and guidance for building accessible, composable React interfaces with its component library.
Provides access to DaisyUI, enabling selection and guidance for Tailwind CSS component classes with a clean, retro-friendly aesthetic.
Provides access to Elastic UI (EUI), enabling selection and guidance for log search, observability, and data-dense telemetry dashboards.
Provides access to GitHub's Primer design system, enabling selection and guidance for developer tools, code review, and GitHub-style workflows.
Provides access to GitLab's design system, enabling selection and guidance for building GitLab-style product interfaces.
Provides access to Mantine, enabling selection and guidance for its React component library, hooks, and styling system.
Provides access to Pinterest's design system, enabling selection and guidance for building Pinterest-style product interfaces.
Provides access to Red Hat PatternFly, enabling selection and guidance for OpenShift/Kubernetes administration consoles and topology graphs.
Provides access to Salesforce's design system, enabling selection and guidance for building enterprise business applications.
Provides access to Shopify Polaris, enabling selection and guidance for merchant administration, e-commerce back-offices, and billing interfaces.
Provides access to Twilio Paste, enabling selection and guidance for accessible customer communication portals.
Provides access to Uber's design system, enabling selection and guidance for building Uber-style product interfaces.
Click on "Install 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., "@UI System Selector MCP Recommend a hidden-gem UI system for a data-heavy admin dashboard"
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.
Empower AI coding agents to discover, compare, select, and strictly adhere to world-class design systems and component libraries ā instead of constantly defaulting to shadcn/ui, MUI, or Bootstrap.
When developers ask AI coding agents (Claude, Cursor, Copilot, ChatGPT, Gemini, etc.) to build web interfaces, the agents almost universally default to the same few mainstream choices:
shadcn/ui
Material UI (MUI)
Tailwind UI / Raw Tailwind divs
Bootstrap
Meanwhile, the software industry has produced dozens of extraordinary, company-backed, battle-tested design systems engineered for specific application domains:
GitHub Primer ā Optimized for developer tools, code review, diffs, and GitHub workflows.
AWS Cloudscape ā Purpose-built for complex cloud management, DevOps consoles, and high-density resource tables.
IBM Carbon ā Engineered for enterprise data analytics, multi-framework apps, and accessibility.
Shopify Polaris ā The gold standard for merchant administration, e-commerce back-offices, and billing.
Adobe React Spectrum ā Built for creative canvas tools and AAA accessibility compliance.
Elastic UI (EUI) ā Specialized in log search, observability, Kibana-like dashboards, and telemetry.
Twilio Paste ā Built with radical focus on accessible customer communication portals.
Grommet ā Accessible, responsive enterprise interfaces with strong layout primitives.
Mantine, HeroUI, Ark UI, Park UI, Ariakit, Kobalte, Web Awesome, and many more.
UI System Selector MCP exposes this rich universe of design systems to AI coding agents via the Model Context Protocol (MCP).
Once a user or agent selects a design system (e.g. "Use GitHub Primer for this project"), the MCP server locks in that selection and instructs the AI coding agent to strictly follow that system's components, tokens, icons, and layout conventions ā and NEVER silently substitute shadcn/ui or MUI.
Related MCP server: CDS Components MCP Server
šļø 40+ Curated Design Systems: Company design systems (GitHub, AWS, IBM, Shopify, Adobe, Elastic, Twilio, Pinterest, Uber, Microsoft, Atlassian, Red Hat, Salesforce, GitLab, ING, plus Nordhealth as a clearly marked restricted-use reference), modern component systems (Mantine, HeroUI, Radix Themes, Chakra UI, Ark UI, Park UI, Ariakit, React Aria Components, Kobalte, Base UI, Blueprint, Semi Design, Arco Design, Ant Design), web components (Web Awesome, Spectrum WC, FAST), and retro aesthetic systems (98.css, XP.css, NES.css, PaperCSS, DaisyUI).
š Explicit Selection Enforcement: Locks the chosen UI system for the active session or project (.ui-system.json). The AI receives explicit directives prohibiting unauthorized component library substitutions.
š Deterministic Natural-Style Search & Ranking: Multi-factor keyword and tag ranking without external LLM latency or cost.
š Hidden Gem Discovery: Recommendation engine with novelty weighting (--hidden-gems) designed to highlight lesser-known production systems rather than echoing mainstream defaults.
āļø Side-by-Side Comparison: Compare 2 to 8 systems across framework support, styling approach, accessibility tier, component density, and use cases.
š¦ Installation & Component Guidance: Instant access to correct package names, peer dependencies, canonical component imports, and official documentation URLs.
š¤ AI Skill Package: Includes skills/ui-system-selector/SKILL.md for compatible coding agents.
š» Human CLI: Fast, colorful CLI tool (ui-systems) sharing the same core registry and logic.
Developer: "Show me UI systems that work well for a developer telemetry dashboard. Give me something unusual or lesser known."
Coding Agent: Calls recommend_ui_systems({ projectType: "developer-tool", preferences: ["dense", "dark-mode", "less-common"], noveltyPreference: "prefer-hidden-gems" })
Result:
Elastic UI (EUI) (Elastic) ā Specialized for log search, data grids, and telemetry.
GitHub Primer (GitHub) ā High-density developer product design system.
Red Hat PatternFly (Red Hat) ā OpenShift/Kubernetes administration and topology graphs.
Twilio Paste (Twilio) ā Accessible, high-trust customer communication workflows.
Developer: "Let's use Primer for this project."
Coding Agent: Calls select_ui_system({ id: "primer", framework: "react", persist: true })
MCP Server Returns Directive:
================================================================================
CRITICAL AI AGENT DIRECTIVE: UI SYSTEM LOCKED TO "GITHUB PRIMER"
================================================================================
The current project has EXPLICITLY selected "GitHub Primer" (@primer/react).
MANDATORY RULES:
ā¢ Implement all user interfaces using official Primer components and primitives.
ā¢ DO NOT introduce or suggest alternative UI libraries (shadcn/ui, MUI, Chakra).
ā¢ Use @primer/octicons-react for iconography.
ā¢ Use ThemeProvider and Box/Stack primitives for layout.
ā¢ Ensure WCAG AA compliance with Primer's focus management.
================================================================================Developer: "Create the repository settings page with an API key revocation modal."
Coding Agent: Calls get_selected_ui_system() and get_component_guidance({ id: "primer", component: "dialog" }). The agent generates UI using @primer/react (PageLayout, Heading, ActionList, Dialog, Button, Flash) rather than generating shadcn Tailwind code.
UI-System-Selector-MCP/
āāā bin/
ā āāā mcp-server.js # Executable entry point for MCP stdio server
ā āāā ui-systems.js # Executable entry point for human CLI
āāā src/
ā āāā index.ts # Public library exports
ā āāā cli/ # Commander CLI implementation
ā āāā server/ # MCP Server (tools, resources, prompts)
ā āāā registry/ # UI Systems registry & search/recommendation engines
ā ā āāā systems/ # Modular per-system definitions (40+ systems)
ā āāā schemas/ # Zod validation schemas and TypeScript types
ā āāā config/ # Selection store and persistence (.ui-system.json)
ā āāā utils/ # Formatting, comparison matrix, and stderr logger
āāā skills/
ā āāā ui-system-selector/ # AI Agent skill documentation
ā āāā SKILL.md
āāā schemas/
ā āāā ui-system-config.json # JSON Schema for persisted project selection
āāā tests/ # Vitest unit & integration test suiteNode.js >= 18.0.0
npm or pnpm / yarn
git clone https://github.com/MossaJehad/UI-System-Selector-MCP.git
cd UI-System-Selector-MCP
npm install
npm run buildAdd ui-system-selector-mcp to your favorite MCP client configuration file:
Add to ~/Library/Application Support/Claude/claude_desktop_config.json (macOS) or %APPDATA%\Claude\claude_desktop_config.json (Windows):
{
"mcpServers": {
"ui-system-selector": {
"command": "node",
"args": ["/ABSOLUTE/PATH/TO/UI-System-Selector-MCP/bin/mcp-server.js"]
}
}
}Add to .cursor/mcp.json in your project or global Cursor settings:
{
"mcpServers": {
"ui-system-selector": {
"command": "node",
"args": ["/ABSOLUTE/PATH/TO/UI-System-Selector-MCP/bin/mcp-server.js"]
}
}
}Add to ~/.gemini/antigravity-cli/mcp/ui-system-selector.json or project MCP settings:
{
"command": "node",
"args": ["/ABSOLUTE/PATH/TO/UI-System-Selector-MCP/bin/mcp-server.js"]
}{
"mcpServers": {
"ui-system-selector": {
"command": "node",
"args": ["/ABSOLUTE/PATH/TO/UI-System-Selector-MCP/bin/mcp-server.js"]
}
}
}Tool Name | Description | Key Arguments |
| Filter & list UI design systems in the catalog |
|
| Multi-factor structured & keyword search |
|
| Get complete detailed metadata, docs, and AI guidelines for a system ID |
|
| Compare 2 to 8 systems in a normalized matrix |
|
| Explicitly select & lock the UI system for the project/session |
|
| Get currently active UI system & mandatory AI rules |
|
| Clear the active selection |
|
| Get package names, install commands, & peer dependencies |
|
| Get canonical component names, import code, & docs |
|
| Discover top system recommendations with novelty filters |
|
ui-systems://catalog ā Full JSON array of all registered UI systems.
ui-systems://selected ā Currently active selection state and agent rules.
ui-systems://categories ā All supported categories with system counts.
ui-systems://tags ā All supported tags with system counts.
ui-systems://systems/{id} ā Full metadata for a specific UI system ID.
build-with-selected-ui-system ā Injects the active design system's tokens, components, accessibility rules, and anti-substitution directives into the agent prompt.
evaluate-ui-system-fit ā Prompts an AI to analyze project requirements against top candidate design systems.
A command-line tool ui-systems is included for developer convenience:
# List all systems
node bin/ui-systems.js list
# Filter systems
node bin/ui-systems.js list --framework react --category developer-tool
# Search systems
node bin/ui-systems.js search "developer tools"
node bin/ui-systems.js search "unusual retro look" --hidden-gems
# Show details & component guidance
node bin/ui-systems.js show primer
node bin/ui-systems.js show primer --component dialog
# Compare systems side-by-side
node bin/ui-systems.js compare primer carbon cloudscape
# Explicitly lock a UI system for your project
node bin/ui-systems.js select primer --persist
# Check active selection
node bin/ui-systems.js selected
# Get smart recommendations
node bin/ui-systems.js recommend "cloud-console" --hidden-gems
# Clear selection
node bin/ui-systems.js clear --remove-persistedWhen persist: true is passed to select_ui_system or --persist is used with the CLI, a lightweight configuration file .ui-system.json is saved in the project root:
{
"$schema": "https://raw.githubusercontent.com/MossaJehad/UI-System-Selector-MCP/main/schemas/ui-system-config.json",
"selectedSystem": "primer",
"framework": "react",
"selectedAt": "2026-09-02T14:00:00.000Z",
"strictMode": true
}This file can be committed to your repository so all team members and AI coding assistants automatically adhere to the same design system. The referenced JSON Schema is included in this repository and in the published npm package, so editors can validate committed configuration files.
Adding a new design system is simple and completely modular:
Create a new file in src/registry/systems/<system-id>.ts:
import { UISystem } from '../../schemas/uiSystem.js';
export const mySystem: UISystem = {
id: 'my-system',
name: 'My Design System',
organization: 'Acme Corp',
description: 'Enterprise design system for high-performance SaaS.',
category: 'enterprise',
frameworks: ['react'],
stylingApproach: 'design-tokens-css',
packageNames: ['@acme/ui'],
docsUrl: 'https://design.acme.com',
repositoryUrl: 'https://github.com/acme/ui',
license: 'MIT',
accessibility: {
wcagLevel: 'AA',
keyboardNav: true,
screenReaderTested: true,
ariaCompliant: true
},
darkMode: true,
rtlSupport: false,
designTokens: { available: true },
icons: { available: true },
maturity: 'production',
opinionatedLevel: 'highly-opinionated',
density: 'compact/dense',
aesthetic: 'Precision engineering aesthetic.',
noveltyLevel: 'hidden-gem',
bestFor: ['Enterprise dashboards'],
avoidFor: ['Casual gaming apps'],
strengths: ['Great data tables'],
weaknesses: ['React only'],
tags: ['enterprise', 'dense', 'dark-mode'],
aiInstructions: {
principles: ['Wrap root in <AcmeProvider>.'],
forbiddenSubstitutions: ['shadcn/ui', '@mui/material'],
themingGuide: 'Use Acme theme tokens.',
iconUsage: 'Use @acme/icons.',
layoutConventions: 'Use Acme Grid and Flex.'
}
};Export your system in src/registry/systems/index.ts and add it to ALL_UI_SYSTEMS.
Run npm test to verify that your new system passes strict Zod schema validation!
Run the comprehensive Vitest test suite:
# Run unit tests
npm test
# Run typecheck
npm run typecheck
# Run linter
npm run lint
# Run tests with V8 coverage
npm run test:coverage
# Verify the production build
npm run build
# Inspect exactly what would be published to npm
npm pack --dry-runAutomatic detection of UI libraries in existing repositories (package.json inspector tool)
Live remote community registry updates
Figma token sync references
Component documentation live search integration
Interactive MCP App webview UI for visual browsing
MIT Ā© Mousa Hasouneh
Clear the currently active UI system selection and optionally remove the .ui-system.json configuration file.
| Name | Required | Description | Default |
|---|---|---|---|
| projectPath | No | Optional project path | |
| removePersisted | No | If true, also removes .ui-system.json if present in the project directory |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden and does disclose the main action and optional file removal. However, it omits side effects such as irreversibility, behavior when no selection exists, and whether the active-selection state is affected when removePersisted is false.
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 a single sentence with the primary action front-loaded and the optional condition clearly appended. Every clause contributes value, and there is no filler or redundancy.
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 two optional parameters and no required fields, the description adequately covers the core behavior and the optional destructive action. Minor gaps include edge-case behavior (e.g., what happens if there is no active selection) and return values, but these are not critical given the schema richness.
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 baseline is 3. The description mostly paraphrases the removePersisted parameter behavior and adds no new semantic detail beyond what the schema already provides for either parameter.
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 uses the specific verb 'Clear' and identifies the resource as the 'currently active UI system selection', which clearly differentiates it from sibling tools like select_ui_system and get_selected_ui_system. It also mentions the optional removal of the .ui-system.json file, adding another layer of specificity.
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 implies the use caseāclearing the active selectionāand communicates the condition for the removePersisted option, but it does not explicitly contrast with sibling tools or state when not to use this tool. The usage guidance is implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Compare 2 to 8 UI systems side-by-side across styling, accessibility, density, opinionated level, strengths, weaknesses, and target domains.
| Name | Required | Description | Default |
|---|---|---|---|
| systems | Yes | Array of UI system IDs to compare (e.g. ["primer", "carbon", "cloudscape"]) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It conveys that this is an analytical, non-mutating comparison and reveals the dimensions evaluated: styling, accessibility, density, opinionated level, strengths, weaknesses, and target domains. However, it does not describe the output format, behavior on invalid system IDs, or any data-fetching implications, so transparency is adequate but incomplete.
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 a single sentence with no filler. The verb, resource, count bounds, and comparison dimensions are all front-loaded, making it immediately scannable for an agent.
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 one-parameter tool, the description is nearly complete: it tells the agent what to pass (2 to 8 UI systems) and what aspects will be compared. Since there is no output schema, it would benefit from a brief note about the result format, but this omission does not prevent correct invocation or tool selection.
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?
The input schema already fully documents the 'systems' parameter, including min/max items, item type, and an example. The description adds only the '2 to 8' count constraint and the UI-system domain, reinforcing rather than extending the schema. Since schema coverage is 100%, a baseline score of 3 is appropriate.
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 states a specific action ('Compare'), a bounded scope ('2 to 8 UI systems'), and the exact comparison dimensions. This clearly distinguishes the tool from siblings like get_ui_system, list_ui_systems, and search_ui_systems, which operate on single systems or lists rather than side-by-side comparison.
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 implies the tool should be used when comparing multiple UI systems side-by-side, which helps separate it from single-system tools. However, it does not explicitly mention when not to use it or name alternatives like recommend_ui_systems for cases where a single recommendation is needed. Usage guidance is present only by implication.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get guidance on canonical component names, import statements, props conventions, accessibility notes, and official documentation links for a specific UI element (e.g. Button, Dialog, Modal, Table, SearchBar, Lozenge).
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | UI system ID (e.g. primer, carbon, cloudscape) | |
| component | Yes | The component name or category (e.g. button, dialog, modal, table, card, navigation) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the behavioral disclosure burden. It clearly indicates a read-only lookup and enumerates the content areas returned, which is meaningful behavioral context; it does not cover failure or edge-case behavior, but none of those are critical for this lookup shape.
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 a single focused sentence that front-loads the action and enumerates concrete output categories. No filler or repetition is present.
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 two-parameter lookup with no output schema, the description conveys the return categories and the input schema fully documents the required parameters. It doesn't explain handling of invalid IDs or exact response structure, but that is a minor gap for this simple tool.
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?
Input schema already documents both parameters at 100% coverage, so the baseline applies. The description adds component examples and the notion of a specific UI element, but it does not add substantial new meaning 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 names a specific verb ('Get guidance') and a specific resource ('canonical component names, import statements, props conventions, accessibility notes, and official documentation links') for a UI element, distinguishing it from system-level sibling tools like get_ui_system and list_ui_systems. Examples such as Button, Dialog, and Table further clarify the target.
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 phrase 'for a specific UI element' gives clear context for when to use this tool, and the output categories make it distinct from system-level siblings. It does not explicitly name alternatives or exclusion conditions, so it stops short of full 5 guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get official package names, installation commands, peer dependencies, and setup instructions for a UI system.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | The UI system ID (e.g. primer, carbon, cloudscape) | |
| framework | No | Target framework (default: react) | react |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the behavioral burden. The verb "Get" and the described outputs strongly suggest a read-only operation with no side effects, but the description does not explicitly confirm this or mention auth requirements, rate limits, or output structure. It is adequate for a simple read tool but leaves some behavioral traits unspecified.
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 a single, front-loaded sentence that states the action and the complete list of returned content without any filler. Every element earns its place, and the length is proportionate to the tool's simplicity.
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 tool with only two parameters and no output schema, the description is largely sufficient: it enumerates the output categories and the schema fully covers the inputs. The main gap is that the output format and any behavioral constraints (such as authentication) remain implicit, but this is minor given the tool's low complexity.
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?
The schema description coverage is 100%, with both `id` and `framework` fully documented, so the schema carries the parameter semantics. The description adds general context about installation content but no parameter-level detail beyond what the schema already provides. Baseline 3 is appropriate.
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 names a specific verb ("Get") and a clear resource (installation details for a UI system), then enumerates the exact return types: package names, installation commands, peer dependencies, and setup instructions. This specificity distinguishes it from sibling tools like get_ui_system or get_component_guidance. An agent knows precisely what this tool provides.
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 gives no explicit guidance on when to use this tool versus alternatives such as get_ui_system, search_ui_systems, or get_component_guidance. There are no preconditions, exclusions, or routing cues. Usage is only vaguely implied by the tool's content focus, which is not enough given the large sibling set.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the currently selected UI system for the active session/project, along with the mandatory implementation rules and constraints for the AI agent.
| Name | Required | Description | Default |
|---|---|---|---|
| projectPath | No | Optional project root path to inspect |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses a valuable behavioral detail: the response includes mandatory implementation rules and constraints for the AI agent. However, it does not mention behavior when no selection exists, whether it is strictly read-only (implied by 'Get'), or how the optional projectPath affects the result.
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?
A single sentence that front-loads the core purpose ('Get the currently selected UI system') and adds the key additional output without any filler. Every word earns its place.
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 getter with one optional parameter, the description adequately states what is returned. However, the absence of an output schema and the large sibling set mean the agent could benefit from knowing the return format or how to distinguish this from get_ui_system. The description is serviceable but leaves some context to inference.
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 schema already documents the only parameter (projectPath) as 'Optional project root path to inspect'. The description adds no further meaning about how projectPath interacts with the active session/project, so a baseline score of 3 is appropriate.
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 uses a specific verb ('Get') and a clearly defined resource ('currently selected UI system'), and also states the additional output of 'mandatory implementation rules and constraints'. This clearly distinguishes it from sibling tools like get_ui_system or list_ui_systems by highlighting the 'selected' scope.
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 does not provide guidance on when to use this tool versus alternatives such as get_ui_system or list_ui_systems. There is no explicit 'use this when' or 'instead of' statement, leaving the agent to infer the intended use from the 'currently selected' phrase alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get complete detailed metadata, design philosophy, accessibility details, component guidance, and AI rules for a specific UI system ID.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | The unique ID of the UI system (e.g. primer, carbon, cloudscape, polaris, react-spectrum, eui, paste, gestalt, base-web, fluent-ui, mantine, heroui, radix-themes, ark-ui, 98-css, etc.) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the burden. The verb 'Get' and the language about returning metadata clearly imply a read-only lookup with no side effects, but the description does not explicitly state that nothing is modified or selected, nor does it disclose any error behavior or prerequisites beyond having a valid ID.
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 a single focused sentence that front-loads the key action and resource, then packs the return-content categories efficiently. There is no filler or redundancy.
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 one-parameter getter with no output schema, the description adequately covers what input is needed and what kind of metadata will be returned. It could be slightly richer by noting how this relates to get_component_guidance, but it is not incomplete for direct invocation.
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 coverage is 100% and the schema already documents the 'id' parameter with examples. The description adds no new parameter-level details beyond reinforcing that the ID must refer to a specific UI system.
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 states a specific verb ('Get') and resource ('complete detailed metadata... for a specific UI system ID'), and enumerates the returned content categories. It clearly distinguishes this tool from siblings like list_ui_systems and search_ui_systems by emphasizing the specific-ID scope.
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 phrase 'for a specific UI system ID' implies the tool is used when a caller already knows the exact ID and needs full details, which is usable guidance. However, it does not explicitly say when to prefer this over siblings like search_ui_systems, get_component_guidance, or select_ui_system.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List available UI design systems and component libraries with optional metadata filters (framework, category, organization, tags, styling, accessibility, novelty).
| Name | Required | Description | Default |
|---|---|---|---|
| tags | No | Filter by tags (e.g. ["dense", "dark-mode", "high-accessibility"]) | |
| limit | No | Maximum number of systems to return | |
| category | No | Filter by category (e.g. company-design-system, enterprise, developer-tool, headless, styled, retro, etc.) | |
| darkMode | No | Filter by dark mode support | |
| framework | No | Filter by supported framework (e.g. react, vue, svelte, solid, web-components, css-only) | |
| rtlSupport | No | Filter by RTL (right-to-left) support | |
| noveltyLevel | No | Filter by novelty level (mainstream, established, hidden-gem, niche-retro) | |
| organization | No | Filter by organization (e.g. GitHub, AWS, IBM, Shopify, Adobe, Microsoft) | |
| stylingApproach | No | Filter by styling approach (e.g. utility-classes, css-in-js, design-tokens-css, unstyled) | |
| opinionatedLevel | No | Filter by opinionated level |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. 'List available...' clearly signals a read-only enumeration operation, which is transparent. However, it does not disclose default limit behavior, ordering, or response shape; for a simple list tool this is acceptable but not rich.
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?
A single sentence, front-loaded with the action and resource, and compact enough to be easily parsed. The parenthetical filter list is a reasonable way to convey the optional filtering capability without bloating the description.
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?
The description is adequate for a straightforward listing operation, but it omits some available filters and provides no differentiation from sibling search tools. With no output schema or annotations, a bit more context about defaults or result behavior would make it fully complete.
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 schema already documents all parameters. The description adds a useful summary of filter dimensions, but it is slightly imprecise: 'accessibility' is not a separate parameter, and darkMode, rtlSupport, and opinionatedLevel are omitted. Overall it does not add significant meaning 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 names the operation ('List') and the resource ('available UI design systems and component libraries'), and it mentions optional metadata filters. It does not explicitly distinguish itself from the sibling search_ui_systems, but the verb + resource combination is specific enough to understand the core purpose.
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 gives no guidance on when to choose this tool over search_ui_systems, compare_ui_systems, or recommend_ui_systems. It implies a listing/filtering use case, but it never states exclusions, prerequisites, or scenarios where a sibling would be more appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recommend 3-7 suitable UI design systems based on project type, framework, and developer preferences, with discovery options to highlight hidden gems rather than defaulting to mainstream choices.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Number of recommendations to return | |
| framework | No | Target frontend framework | react |
| preferences | No | Preferences such as ["dense", "dark-mode", "less-common", "high-accessibility", "headless", "styled"]. Use "allow-restricted" only when authorized to consider restricted-use systems. | |
| projectType | Yes | Type of project (e.g. "developer-tool", "saas-dashboard", "e-commerce", "cloud-console", "creative-tool", "healthcare", "retro-game", "fintech") | |
| noveltyPreference | No | Discovery filter: use "prefer-hidden-gems" to discover lesser-known production systems instead of mainstream defaults | all |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the behavioral disclosure burden. It adds useful context: the output range (3-7), the influence of project type/framework/preferences, and a deliberate bias toward hidden gems. It does not disclose edge cases, return value details, or authorization implications of preferences like 'allow-restricted', but it is not misleading.
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 a single, front-loaded sentence. It names the action, object, result count, and key inputs without filler, and the 'hidden gems' phrase earns its place by conveying the tool's differentiator.
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?
The description is adequate for basic invocation: it implies the required projectType and the optional framework/preferences inputs, and the schema fills in the remaining parameter details. However, with no output schema, it does not describe what fields each recommendation will contain, nor does it explain behavior when no systems match or how noveltyPreference affects the result set.
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 baseline is 3. The description mentions projectType, framework, preferences, and discovery options at a high level but adds no semantic detail beyond what the schema already provides for each parameter.
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 states a specific action and object: 'Recommend 3-7 suitable UI design systems'. It also names the key inputs (project type, framework, developer preferences) and a distinctive discovery focus ('hidden gems rather than defaulting to mainstream choices'), which clearly sets it apart from sibling tools like list_ui_systems and search_ui_systems.
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 implies when to use the tool: when an agent needs curated recommendations based on project type, framework, and preferences. However, it gives no explicit comparison to sibling tools, no when-not-to-use conditions, and no guidance on when to choose list_ui_systems or search_ui_systems instead.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search UI systems using natural language queries, keywords, tags, or concepts (e.g. "developer tool dashboard", "GitHub like design systems", "unusual retro look", "accessible React components", "systems that don't look like shadcn").
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max results to return | |
| query | Yes | Search query string | |
| category | No | Optional category filter | |
| framework | No | Optional framework filter | |
| noveltyPreference | No | Discovery preference (use prefer-hidden-gems or niche-retro to find less obvious alternatives) | all |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only describes input semantics and doesn't disclose likely read-only behavior, result ranking/relevance, output shape, or how filters like noveltyPreference affect results. It doesn't contradict annotations, but it under-discloses.
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 a single focused sentence with the verb and resource front-loaded. The parenthetical examples are numerous but earn their place by clarifying what counts as a valid natural-language query. There is no filler or repetition.
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?
With no output schema and no annotations, the description carries more responsibility. It effectively guides the agent on query phrasing but doesn't describe the return value, ordering, default limits, or how this tool relates to list/get/compare siblings. It is enough for a basic invocation but not fully complete for nuanced tool selection.
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 baseline is 3. The description adds meaningful semantics for the query parameter by explaining that it accepts natural language, keywords, tags, or concepts and giving concrete example queries not present in the schema. Other parameters are adequately covered by their schema descriptions.
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 uses a specific verb and resource: 'Search UI systems', and elaborates the query modes (natural language, keywords, tags, concepts) with concrete examples. It clearly conveys a discovery-oriented purpose, though it does not explicitly differentiate from sibling tools like list_ui_systems.
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 implies when to use it: when the user wants to find UI systems by concept, style, or description rather than by known identity. However, it doesn't explicitly state when not to use it or mention alternatives such as get_ui_system for a specific system or list_ui_systems for unfiltered enumeration.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Select the UI design system to be used by the AI coding agent for this project/session. Strict mode locks the selection and prohibits unrequested library substitutions.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | The unique ID of the UI system to select (e.g. "primer", "carbon", "cloudscape") | |
| persist | No | If true, writes the selection preference to .ui-system.json in the project root | |
| framework | No | Target framework (default: react) | react |
| strictMode | No | If true, instructs the AI that substituting another library is strictly prohibited | |
| projectPath | No | Optional project root path for persistence (defaults to current working directory) | |
| acknowledgeUsageRestrictions | No | Must be true to select a system whose license or terms restrict general use |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral disclosure burden. It does disclose that strict mode locks the selection and prohibits unrequested library substitutions, which is useful. However, it does not mention other behaviors such as overwriting an existing selection, persistence effects, or any restrictions/acknowledgement requirements.
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?
Two sentences with no filler. The first sentence front-loads the core purpose, and the second adds the most important behavioral caveat. Every sentence earns its place.
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?
The schema covers all parameters, but the tool has six parameters, no output schema, and no annotations. The description is adequate for basic selection but leaves gaps around persistence, restricted-license acknowledgement, and what happens to a previously selected system.
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 baseline is 3. The description only maps to strictMode via 'Strict mode' and does not add any meaning beyond the schema for id, persist, framework, projectPath, or acknowledgeUsageRestrictions.
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 uses a specific action verb ('Select') with a clear resource ('UI design system') and scope ('for this project/session'). This clearly distinguishes it from the read/search/compare/recommend sibling tools, and from clear_selected_ui_system.
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 implies when to use the tool: when the AI coding agent needs a UI design system selected for the current project or session. However, it does not explicitly contrast it with alternatives such as get_selected_ui_system, recommend_ui_systems, or clear_selected_ui_system, leaving usage boundaries to be inferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Each tool addresses a distinct interaction typeāretrieval by ID, filtered listing, natural language search, comparison, component guidance, selection state, installation, and recommendation. The only mild overlap is between list, search, and recommend, all returning UI systems, but their query modes differ enough to minimize misselection.
All tools follow a consistent verb_noun snake_case pattern (get_, list_, search_, compare_, select_, clear_, recommend_). Compound names like get_selected_ui_system remain predictable and readable.
10 tools is squarely in the well-scoped range for a UI system selector. Each tool covers a necessary step in discovering, evaluating, selecting, and installing a design system without bloat or redundancy.
The server covers the full workflow: discovery (list, search, recommend), deep inspection (get, compare, component guidance, installation), and session state management (select, get selected, clear). There are no obvious dead ends or missing operations for the stated purpose.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Live React design-system APIs, patterns, and code validation so AI agents build real UI, not slop.
Serves your design system and coding standards to coding agents, so they stop guessing.
Design intelligence for coding agents: audits, design systems, and a taste profile agents consult.
A design-style library for AI agents: search real styles, fetch a ready-to-apply design spec.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/MossaJehad/UI-System-Selector-MCP'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
