The its-just-ui MCP Server enables AI-powered generation, customization, and documentation of React components directly within Cursor IDE.
Core Capabilities:
Component Generation & Composition: Create individual its-just-ui components with specified props, children, and Tailwind CSS styling, or combine multiple components into structured layouts (vertical, horizontal, grid)
Component Discovery: Browse and list available components by categories (form, navigation, data-display)
Theme Configuration: Set up global theme settings including color modes (light, dark, system), custom colors, font families, and border radii
Tailwind Utilities: Generate specific Tailwind CSS utility classes for spacing, colors, typography, layout, and effects
Responsive Layouts: Create responsive designs using Tailwind CSS with support for grid, flexbox, container, sidebar, hero, and card-grid layouts
Form Generation: Build complete forms with various input types, validation, and layout options (single-column, two-column, inline)
Documentation & Accessibility: Retrieve component documentation with usage examples, prop descriptions, and accessibility features including ARIA attributes for compliance
Provides tools for generating, customizing, and documenting React components from the its-just-ui component library, including component generation with props, theme management, and form creation.
Generates Tailwind CSS utility classes and responsive layouts, creates spacing/typography configurations, and provides tools for building responsive design patterns.
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., "@its-just-ui MCP Server Generate a primary button with loading state"
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.
A Model Context Protocol (MCP) server optimized for Cursor IDE, enabling AI-powered generation, customization, and documentation of its-just-ui React components directly in your editor.
Native MCP Support: Cursor has built-in support for MCP servers via stdio
AI-Powered Component Generation: Generate complete its-just-ui components with a simple prompt
Contextual Awareness: The AI understands your project structure and existing code
Zero Configuration: Works out of the box with minimal setup
š Quick Start for Cursor
āļø Cursor Configuration
š ļø Available Tools in Cursor
š” Cursor Usage Examples
š Alternative: Claude Desktop
Development
Troubleshooting
License
# Simply add to your Cursor config - no installation needed!
# Cursor will handle everything via npx# Clone and build
git clone https://github.com/its-just-ui/its-just-mcp.git
cd its-just-mcp
npm install && npm run buildRelated MCP server: 21st.dev Magic AI Agent
Create .cursor/mcp.json in your React project root:
{
"mcpServers": {
"its-just-ui": {
"command": "npx",
"args": ["-y", "its-just-mcp"],
"env": {}
}
}
}Create ~/.cursor/mcp.json:
{
"mcpServers": {
"its-just-ui": {
"command": "npx",
"args": ["-y", "its-just-mcp"],
"env": {}
}
}
}If you're developing the MCP server locally:
{
"mcpServers": {
"its-just-ui": {
"command": "node",
"args": ["/absolute/path/to/its-just-mcp/dist/index.js"],
"env": {}
}
}
}After adding the configuration, restart Cursor to load the MCP server.
In Cursor, you can ask the AI:
"What MCP tools are available?"
"Generate a Button component using its-just-ui"
Ask Cursor AI to generate components directly in your code:
"Add a primary button with loading state here"
"Create a card grid layout with 3 columns"
"Generate a login form with validation"The MCP server understands your project context:
Existing theme configuration
Component usage patterns
Project structure
Generate: ā+K ā "Generate [component] with [props]"
Document: ā+K ā "Document this its-just-ui component"
Theme: ā+K ā "Configure dark theme for its-just-ui"
Form: ā+K ā "Create a contact form with validation"
Tool | Cursor Command Example | Description |
| "Generate a primary button" | Create any its-just-ui component |
| "Show me all form components" | Browse available components |
| "Create a card grid layout" | Compose multiple components |
Tool | Cursor Command Example | Description |
| "Set up dark mode theme" | Configure ThemeProvider |
| "Generate spacing utilities" | Create Tailwind utility classes |
| "Make a responsive grid" | Build responsive layouts |
Tool | Cursor Command Example | Description |
| "Build a contact form" | Generate complete forms |
| "Show Button documentation" | Get component docs |
| "Check Dialog accessibility" | Review ARIA attributes |
In Cursor, simply type ā+K and ask:
"Generate a primary button with loading state"The AI will use the MCP server to generate:
<Button variant="primary" loading={true}>
Processing...
</Button>"Create a login form with email and password validation"Result:
<form onSubmit={handleSubmit}>
<Input
type="email"
name="email"
label="Email"
required
placeholder="Enter your email"
/>
<Input
type="password"
name="password"
label="Password"
required
minLength={8}
/>
<Button type="submit" variant="primary">
Login
</Button>
</form>"Set up a dark theme with blue primary color"Result:
<ThemeProvider
theme={{
mode: "dark",
colors: {
primary: "#3b82f6",
secondary: "#64748b"
}
}}
>
{children}
</ThemeProvider>While this server is optimized for Cursor, it also works with Claude Desktop:
macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
Windows: %APPDATA%\Claude\claude_desktop_config.json
{
"mcpServers": {
"its-just-ui": {
"command": "npx",
"args": ["-y", "its-just-mcp"],
"env": {}
}
}
}# Install dependencies
npm install
# Run in development mode
npm run dev
# Build for production
npm run build
# Run tests
npm test# ESLint
npm run lint
# Prettier
npm run format# Jest
npm test
# Watch mode
npm run test:watch
# Coverage
npm run test:coverageits-just-mcp/
āāā src/
ā āāā index.ts # Main server entry point
ā āāā components/
ā ā āāā registry.ts # Component definitions and metadata
ā āāā tools/
ā āāā componentGenerator.ts # Component generation logic
ā āāā themeManager.ts # Theme configuration tools
ā āāā utilityTools.ts # Utility and layout tools
ā āāā documentationTools.ts # Documentation and accessibility
āāā dist/ # Compiled output
āāā package.json
āāā tsconfig.json
āāā README.mdContributions are welcome! Please feel free to submit a Pull Request.
Recommended steps:
Fork the repo and create a feature branch
Add tests for new behavior
Run lint and tests locally
Open a PR with a clear description and examples
MIT
For issues or questions, please open an issue on GitHub or contact the maintainers.
Cursor IDE - The AI-first code editor
Issue | Solution |
MCP tools not available | 1. Restart Cursor2. Check |
"Command not found: npx" | Install Node.js 18+ and npm |
Server not responding | 1. Check Cursor Console (View ā Output ā MCP)2. Try local installation instead of npx |
Tools not showing in AI | Ask "What MCP tools are available?" to refresh |
# Verify Node version (needs 18+)
node --version
# For local development, rebuild
cd /path/to/its-just-mcp
npm run build
# Check MCP config is valid JSON
cat .cursor/mcp.json | jq .
# Clear npm cache if npx fails
npm cache clean --forceCheck Cursor Console: View ā Output ā MCP
Cursor MCP Docs: https://cursor-docs.apidog.io/model-context-protocol
Open an issue: https://github.com/its-just-ui/its-just-mcp/issues
Get accessibility features and ARIA attributes for a component
| Name | Required | Description | Default |
|---|---|---|---|
| component | Yes | Component name |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosing behavioral traits. It only states that the tool 'gets' data, but does not disclose any potential side effects, error conditions, or performance characteristics.
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 unnecessary words. It is appropriately sized and front-loaded with the key action and resource.
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?
Given the simplicity of the tool (1 parameter, no output schema) and the sibling set, the description adequately identifies the tool's purpose but does not describe the return format or provide enough context for an agent to decide between this and similar tools.
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 already covers the parameter description ('Component name') completely (100% coverage). The tool description adds no additional meaning beyond the schema, 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 clearly states the verb 'Get' and the resource 'accessibility features and ARIA attributes for a component'. It effectively distinguishes from sibling tools like 'get_component_docs' and 'list_components' which serve different purposes.
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 lacks any guidance on when to use this tool versus alternatives. No context is provided for usage scenarios, exclusions, or best practices.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a composition of multiple its-just-ui components
| Name | Required | Description | Default |
|---|---|---|---|
| components | Yes | ||
| layout | No | Layout for composition |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral transparency. It does not disclose side effects, whether the tool is destructive, permissions needed, or what happens with the composition (e.g., persistent or transient). The description is too minimal to inform safe usage.
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 one sentence, which is concise. However, it sacrifices necessary detail for brevity. It front-loads the purpose but does not earn its place with additional value beyond stating the obvious.
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?
Given the tool's moderate complexity (2 parameters, 1 optional with enum, no output schema) and lack of annotations, the description is insufficient. It does not cover return values, behavior, or how the composition is generated. Sibling tools like 'create_form' and 'generate_component' would benefit from more context.
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 has 2 parameters with 50% description coverage; only 'layout' has a description. The tool description adds no parameter semantics beyond the schema. For 'components', the format (array of objects with type, props, children) is not explained, leaving ambiguity about required nested properties.
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 the tool's purpose as creating a composition of its-just-ui components. It uses a specific verb ('Create') and resource ('composition of multiple its-just-ui components'). However, it does not differentiate from sibling tools like 'create_form' or 'generate_component', which have overlapping functionality.
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 offers no guidance on when to use this tool versus alternatives. It does not mention prerequisites, context, or scenarios where this tool is preferred over siblings like 'create_responsive_layout' or 'configure_theme'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Configure theme settings including colors, mode, and typography
| Name | Required | Description | Default |
|---|---|---|---|
| mode | No | ||
| colors | No | ||
| borderRadius | No | ||
| fontFamily | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description must disclose behavioral traits, but it only states 'configure', which implies mutation. It does not clarify whether settings are merged or replaced, what permissions are required, or any side effects.
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 concise sentence, front-loading the purpose. However, the brevity leaves important gaps, making it slightly under-specified.
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?
Given no annotations, no output schema, and nested objects, the description is insufficient. It lacks details on default behavior, response, or how partial updates work, leaving the agent with inadequate information.
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 0%, so the description must explain parameters. It only mentions 'colors, mode, and typography', partially mapping to the schema (mode, colors, borderRadius, fontFamily). No details on color format, border radius units, or font family syntax are provided.
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 verb 'configure' with the resource 'theme settings' and lists specific categories (colors, mode, typography), clearly indicating the tool's function. It distinguishes from sibling tools that focus on component generation or accessibility.
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?
No guidance is provided on when to use this tool over alternatives, nor any context about prerequisites or use cases. The agent receives no help in deciding whether to invoke this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate a form structure using its-just-ui form components
| Name | Required | Description | Default |
|---|---|---|---|
| fields | Yes | ||
| layout | No | ||
| includeValidation | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must fully disclose behavioral traits. It states the tool 'generates' a form structure, implying a non-destructive creation, but omits important details such as whether the result is returned, stored, or requires specific permissions. The lack of output schema further reduces transparency.
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, which is too minimal given the tool's complexity. It lacks structure and does not break down the purpose or parameters. While concise, it sacrifices useful information, making it inefficient.
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?
Considering the absence of annotations, output schema, and only 0% schema coverage, the description is grossly insufficient. It does not explain return values, field structure, layout options, or validation behavior, leaving the agent without critical context for correct usage.
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 has three parameters with 0% description coverage. The description does not explain any parameter, leaving the agent to infer meaning from names and enums alone. For example, 'fields' is a complex array of objects but is not described. The description adds no semantic value 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 the tool's purpose: generate a form structure using specific components. The verb 'generate' and resource 'form structure' are specific. However, it could be more precise by mentioning that the form is a JSON definition with fields, layout, and validation. Still, it distinguishes this tool from siblings like 'generate_component' or 'compose_components' by focusing on forms.
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?
No guidance is provided about when to use this tool versus alternatives. There is no mention of prerequisites, context, or situations where it is appropriate. Users are left to infer usage from the name and description only.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a responsive layout using Tailwind CSS and its-just-ui components
| Name | Required | Description | Default |
|---|---|---|---|
| type | Yes | ||
| breakpoints | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behaviors. It fails to mention creation side effects (e.g., file overwrites, workspace changes), required permissions, or return values. The word 'Create' implies a mutation, but no further details are provided.
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 that essentially restates the tool name without adding valuable insight. It is under-specified rather than concise, lacking any supplementary information to aid tool selection or usage.
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?
Given the nested object parameter, no output schema, and zero annotation coverage, the description should provide rich context about what the tool produces and expects. It only states a generic purpose, leaving significant gaps for an AI agent.
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 0%, and the description adds no meaning beyond the property names. It does not explain the 'type' enum values (e.g., grid vs flexbox) or the expected format for 'breakpoints' keys, leaving the agent to infer from names alone.
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 the verb 'Create' and the resource 'responsive layout using Tailwind CSS and its-just-ui components', which is specific. It distinguishes this tool from siblings like create_form or compose_components by focusing on layout creation, though no explicit differentiation is provided.
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?
No guidance is given on when to use this tool versus alternatives. There is no mention of prerequisites, exclusions, or context for selection, leaving the agent without decision support.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate an its-just-ui component with specified props and styling
| Name | Required | Description | Default |
|---|---|---|---|
| component | Yes | Name of the its-just-ui component | |
| props | No | Props to pass to the component | |
| children | No | Children content for the component | |
| className | No | Additional Tailwind CSS classes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description should disclose side effects, permissions, or output behavior. It only says 'generate' without clarifying if it creates a file, returns code, or modifies state.
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, concise but incomplete. It lacks detail to earn a higher score while still being minimally acceptable.
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?
Given the tool has 4 parameters, one required, and no output schema, the description should explain what 'generate' means (e.g., code output, file creation). It also fails to differentiate from similar sibling tools like compose_components.
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 descriptions cover all parameters (100%), so the description doesn't need to explain them, but it adds no extra meaning about how props, children, and className interact. 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?
Description clearly states it generates an its-just-ui component with props and styling, which is specific and distinct from sibling tools like list_components or compose_components.
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?
No guidance on when to use this tool vs alternatives. No mention of prerequisites, when not to use, or which sibling tool to choose. The description is silent on usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate Tailwind utility classes for specific use cases
| Name | Required | Description | Default |
|---|---|---|---|
| type | Yes | ||
| values | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It only says 'generate', implying creation, but doesn't state side effects, permissions, or output nature. As a generation tool, it likely doesn't mutate state, but this isn't clarified.
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?
Single sentence, no wasted words, but lacks details. It's brief but not effectively concise as it sacrifices informativeness. Front-loaded with main verb but otherwise minimal.
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?
No output schema exists, and the description doesn't describe return values, error behavior, or usage examples. For a tool with an enum and an object parameter, this is incomplete for an AI agent to use correctly.
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 0% and the description does not explain any parameters. The enum for 'type' is self-explanatory but not elaborated, and 'values' (an object) is completely unexplained. No added 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?
Description states 'Generate Tailwind utility classes for specific use cases' which is a generic purpose. It doesn't specify what kind of use cases or output format, and while it distinguishes from component-focused siblings like compose_components, it's still vague.
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?
No guidance on when to use this tool vs alternatives like create_form or get_component_docs. No mention of prerequisites or limitations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get documentation, usage examples, and prop descriptions for a component
| Name | Required | Description | Default |
|---|---|---|---|
| component | Yes | Component name | |
| section | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose behavioral traits such as side effects, authorization needs, rate limits, or whether the tool is read-only. It merely states the function without behavioral context.
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?
Single sentence is concise and front-loaded with purpose, but lacks structure such as parameter descriptions or usage notes.
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?
Given 2 parameters, no output schema, and no annotations, the description is too sparse. It does not specify what each parameter does, the shape of the returned data, or any prerequisites, leaving the agent underinformed.
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 50%, and the description adds minimal meaning beyond the schema. It does not explain the section parameter or its enum values, nor how the output relates to the parameters.
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?
Description uses specific verb 'Get' and resource 'documentation, usage examples, and prop descriptions for a component', clearly distinguishing it from sibling tools that perform actions like checking accessibility or composing components.
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?
Description implies usage for retrieving component docs but provides no explicit guidance on when to use this tool versus siblings like check_accessibility or list_components.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List available its-just-ui components and their categories
| Name | Required | Description | Default |
|---|---|---|---|
| category | No | Filter components by category |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description must fully disclose behavioral traits. It fails to mention that the tool is read-only, whether it returns a list, or any side effects, authentication needs, or rate limits.
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?
Single sentence front-loaded with the verb 'List', no extraneous words. Every part 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 tool with one optional parameter and no output schema, the description is adequate but lacks detail on the return format or any usage hints. It covers the essentials but could be more 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 coverage is 100% with a clear enum and description for 'category'. The description adds nothing beyond the schema, so 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 clearly states the action ('List'), the resource ('available its-just-ui components'), and includes what is returned ('their categories'). It distinguishes from siblings like 'get_component_docs' and 'generate_component'.
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?
No guidance on when to use this tool versus alternatives, such as using it for browsing before selecting a component or for overview purposes. Missing context on prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
check_accessibilitycompose_componentsconfigure_themecreate_formcreate_responsive_layoutgenerate_componentgenerate_tailwind_classesget_component_docslist_componentsEach tool has a clearly distinct purpose with no overlap. For example, 'check_accessibility' focuses on ARIA features, 'compose_components' handles component composition, and 'generate_component' creates individual components. The descriptions specify unique functions, making it easy for an agent to select the right tool.
All tool names follow a consistent verb_noun pattern using snake_case, such as 'check_accessibility', 'configure_theme', and 'generate_component'. This predictable naming scheme enhances readability and usability for agents, with no deviations or mixed conventions.
With 9 tools, the server is well-scoped for its purpose of UI component management and generation. Each tool serves a specific role, from documentation retrieval to layout creation, and none feel redundant or missing, making the count appropriate for the domain.
The toolset covers core UI workflows comprehensively, including component generation, theming, layout, forms, and documentation. A minor gap exists in lacking update or delete operations for components or themes, but agents can likely work around this for most tasks.
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.
Build and manage your design system with AI: tokens, themes, components, icons, Figma and code.
Generate, inspect, and manage Flowstep UI designs directly from your AI assistant.
UI design from prompts, screenshots, and URLs for AI coding agents and theme tokens.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/its-just-ui/its-just-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
