UI System Selector MCP
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
| prompts | {
"listChanged": true
} |
| resources | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| list_ui_systemsB | List available UI design systems and component libraries with optional metadata filters (framework, category, organization, tags, styling, accessibility, novelty). |
| search_ui_systemsB | 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"). |
| get_ui_systemA | Get complete detailed metadata, design philosophy, accessibility details, component guidance, and AI rules for a specific UI system ID. |
| compare_ui_systemsA | Compare 2 to 8 UI systems side-by-side across styling, accessibility, density, opinionated level, strengths, weaknesses, and target domains. |
| select_ui_systemA | 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. |
| get_selected_ui_systemA | Get the currently selected UI system for the active session/project, along with the mandatory implementation rules and constraints for the AI agent. |
| clear_selected_ui_systemA | Clear the currently active UI system selection and optionally remove the .ui-system.json configuration file. |
| get_installationA | Get official package names, installation commands, peer dependencies, and setup instructions for a UI system. |
| get_component_guidanceA | 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). |
| recommend_ui_systemsA | 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. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
| build-with-selected-ui-system | |
| evaluate-ui-system-fit |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
| catalog | |
| selected | |
| categories | |
| tags |
TDQS
Scored across 10 tools
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.