web-ui-component-spec-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": false
} |
| experimental | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| list_componentsA | List all components in the Web UI Component Specification. Returns name, id, category, tier, and one-line summary for each. Always call this first in a new session to establish what exists. Optionally filter by category or tier. |
| get_component_specA | Return the full behavioral specification for a single component. Includes description, all main features, secondary features (accessibility, keyboard navigation, touch, responsive, i18n, etc.), and implementation notes. Use this when implementing a component from scratch. |
| get_component_testsA | Return only the Test Scenarios for one or more components. Use this when writing tests or reviewing an implementation against the spec. More token-efficient than get_component_spec when tests are all you need. |
| get_component_summaryA | Return a lightweight summary for one or more components — description and main features only, no secondary features or test scenarios. Use this for planning and surveying before deep implementation work. |
| get_components_by_scenarioA | Return a curated component list and recommended build order for a project type. Use this when starting a library from scratch to get a sensible scope and sequence. Pass 'list' as scenario to see all available options. |
| get_core_principlesA | Return content from the Core Principles section of the spec. Fetch only the section you need to minimize context usage. Use 'philosophy' when starting any component work. Use 'design_tokens' when reviewing token definitions. Use 'all' sparingly. |
| get_step_by_stepA | Return one or more steps from the Step-by-Step Build Guide. Fetch only the steps relevant to the current phase of work. e.g. pass [1, 2, 3] when defining design tokens, [7, 8] when building components. |
| get_related_componentsA | Return dependency and relationship information for a component: what it depends on, what depends on it, and what it's commonly confused with. Call this before implementing to understand what needs to be built first. |
| search_componentsA | Fuzzy search across component names, descriptions, and features. Use this when you know what behavior you need but not which component provides it. e.g. 'focus trap', 'date range', 'file upload', 'keyboard navigation' |
| validate_component_checklistA | Compare an implementation against the spec's Main Features and Test Scenarios. Returns a coverage report showing what's covered, what's missing, and an overall status. Use this to QA a component before marking it done. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 10 tools
Each tool has a uniquely scoped purpose with no overlap. For example, get_component_spec returns full specs while get_component_summary returns only top-level info. Search and list tools target different access patterns. Naming and descriptions clearly distinguish them.
All tools follow a consistent verb_noun pattern using snake_case (e.g., get_component_spec, list_components, validate_component_checklist). The naming is predictable and intuitive.
10 tools is well-scoped for a specification server. Each tool addresses a distinct need (listing, searching, retrieving specs, tests, principles, dependencies, build steps, validation) without redundancy or excess.
The tool set covers the full lifecycle of working with component specs: discovery (list, search), detailed retrieval (spec, summary, tests, principles, related components), guided implementation (step-by-step), and quality assurance (validate checklist). No obvious gaps for the stated domain.