ui-react-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| UI_REACT_METADATA | No | To use a local checkout of ui-react instead of the bundled metadata, set UI_REACT_METADATA to the path of its lib/metadata/components.json. |
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
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| list_componentsA | Lists every component available in @alexcruzgargallo/ui-react with a short description. |
| get_componentA | Returns the full documentation of a component: import statement, props with their allowed values and defaults, and a usage example. Use it before writing code with the component. |
| search_componentsA | Finds components that match what the user wants to build, e.g. 'loading', 'form field' or 'status label'. |
| get_usage_exampleA | Generates a JSX example for a component. Optional props are validated against the library, so invalid variants or sizes are reported instead of silently used. |
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 4 tools
list_components and search_components partly overlap (both surface components), though enumerate-vs-filter is a meaningful distinction. More problematic is that get_component already returns a usage example while get_usage_example separately generates a JSX example, so an agent may be unsure which to call for examples.
All four tools follow a clean verb_noun snake_case pattern (list_components, get_component, search_components, get_usage_example). The singular/plural difference reflects the actual semantics (one component vs many), not inconsistent convention.
Four tools is reasonable for a read-only component documentation server covering enumerate, fetch, search, and example generation. It is slightly thin — no category/browse or prop-lookup tool — but nothing is redundant at the count level.
The surface covers the core documentation lifecycle: discover (list/search), inspect (get_component), and apply (get_usage_example). Minor gaps like listing component categories or searching by prop are workarounds an agent can handle.