Skip to main content
Glama
HelloGGX

shadcn-vue-mcp

by HelloGGX
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

A powerful AI Agent tool that helps developers instantly create high-quality UI components

GitHub forks GitHub stars GitHub commits License Contributors

Shadcn-vue MCP Server is a powerful AI-driven tool that helps developers instantly create beautiful, modern UI components through natural language descriptions. It integrates the shadcn-vue component library and tailwindcss, seamlessly connects with mainstream IDEs, and provides a streamlined UI development workflow.

❌ Without shadcn-vue MCP

Developers face multiple challenges when building UI components:

  • ❌ Tedious Development Workflow: Constantly switching between the IDE, official documentation, and browser severely impacts development efficiency and focus.

  • ❌ Difficulty in Component Selection: Faced with numerous components from shadcn-vue, developers struggle to quickly find the best fit for their needs without intelligent recommendations.

  • ❌ High Repetitive Workload: Involves manually writing extensive boilerplate code and handling various component states and complex interaction logic.

  • ❌ Insufficient Quality Assurance: It's easy to overlook quality standards like accessibility (A11y), performance optimization, and best coding practices, leading to inconsistent component quality.

  • ❌ High Maintenance Costs: As the project grows, manually maintaining the style, behavior, and dependencies of all components becomes exceptionally difficult, making consistency hard to achieve.

Related MCP server: Shadcn Registry manager

✅ With shadcn-vue MCP

shadcn-vue MCP provides an intelligent UI component development experience that revolutionizes the traditional workflow:

  • ✅ One-Stop Development Experience: Complete the entire process—from component selection and coding to preview—without ever leaving your editor, simply by describing your needs in natural language.

  • ✅ Intelligent Component Recommendation: The components-filter tool intelligently analyzes your requirements and recommends the most suitable shadcn-vue components.

  • ✅ High-Quality Code Auto-Generation: component-builder automatically generates high-quality Vue component code that complies with shadcn-vue and tailwindcss standards, with best practices built-in.

  • ✅ Built-in Quality Assurance: component-quality-check automatically performs accessibility (A11y) and code quality checks on the generated code, ensuring professional-grade components.

  • ✅ Instant Documentation and Previews: component-usage-doc provides real-time component documentation, APIs, and usage examples to get you started immediately.

  • ✅ Ensures High Design Consistency: All generated components strictly adhere to a unified design specification, ensuring visual and interactive consistency across the entire application and enhancing brand value.

🌟 Features

  • Natural Language Descriptions:

    • AI-Powered UI Generation: Create UI components by describing them in natural language

  • Multi-IDE Support:

    • Cursor IDE integration for seamless workflows.

    • Trae support for advanced AI-driven development.

    • VSCode support for a robust coding experience.

    • VSCode + Cline integration (Beta) for enhanced collaboration.

  • Modern Component Library:

    • Built on the shadcn-vue component library and tailwindcss for modern, responsive designs.

  • TypeScript Support:

    • Full TypeScript support ensures type-safe and scalable development.

  • Intelligent Documentation Query:

    • Real-time access to detailed shadcn-vue component documentation with integrated previews of usage and best practices.

  • Component Enhancement:

    • Accessibility: WCAG 2.1 compliant, keyboard navigation, ARIA support

    • Performance: Code splitting, tree shaking, optimized bundles

    • Consistency: Unified design system, consistent behavior patterns

    • Maintainability: Clean code architecture, well-documented components

    • Developer Experience: TypeScript support, hot reload, intuitive APIs

🚀 Getting Started

Prerequisites

Before you begin, ensure you have Node.js installed on your system.

  • Recommended Node.js version: 18.20.1 or later.

Using a different version might lead to installation errors like Error: spawnSync code-insiders.cmd EINVAL. Downgrading or upgrading to the recommended version is the best solution.

Qucik install: URL Quick Installation for copilot

First, you need to obtain a unique connection URL from the Smithery service that contains your personal credentials. Visit the shadcn-vue-mcp page on Smithery.

Step 1. Click the Generate URL button on the page.:

The system will generate a unique URL for you, which includes an API key for authentication. Copy this entire URL.

Step 2. Open vscode, open copilot and select Agent model, Next, add the URL you just obtained to your IDE's MCP configuration file.

  1. In your IDE project, find or create the configuration file named mcp.json.

  2. Add or merge the following JSON object into the servers field of that file.

Step 3: for vscode IDE, Select Add Server

Step 4: choose HTTP(HTTP or Server-Sent Events)

Step 5: paste the URL

Step 6: config like this:

{
  "servers": {
    "shadcn-vue-mcp": {
      "url": "https://server.smithery.ai/@HelloGGX/shadcn-vue-mcp/mcp?api_key=xxxx&profile=linguistic-landfowl-TWeEt8"
    }
  }
}

Config file locations:

  • Cursor: ~/.cursor/mcp.json

  • Trae: ~/.Trae/mcp.json

  • Cline: ~/.cline/mcp_config.json

  • Claude: ~/.claude/mcp_config.json

🛠️ Tool List & Core Features

Component Generation Tools

  • requirement-structuring

    • Analyzes natural language requirements

    • Converts user needs into structured JSON format

    • Considers core functionality and essential features

    • Built-in user interaction and edge case analysis

Documentation & Analysis Tools

  • component-usage-doc

    • Real-time access to shadcn-vue component documentation

    • Interactive preview of component variants

    • Built-in markdown rendering in browser

    • Detailed API and usage examples

Component Filtering & Management

  • components-filter

    • Smart component recommendation system

    • Supports multi-language description parsing

    • Component relationship analysis

    • Usage frequency statistics and weighting

Code Quality & Testing

  • component-quality-check

    • Automated code quality assessment

    • A11y (Accessibility) compliance checking

    • Performance optimization suggestions

    • Best practices validation

Smart Code Generation

  • component-builder

    • AI-powered component generation

    • shadcn-vue and Tailwind CSS integration

    • TypeScript type safety

    • Built-in best practices implementation

Result Example

User: /ui create a flight display component

AI: Generated code as follows:

UI Component Example

User: /check

AI: alt text

AI: Generated code as follows:

🤝 Contribution Guide

We welcome all forms of contributions! You can help us improve @agent/shadcn-vue by:

  • Reporting Bugs: If you find a bug, please create an issue in our GitHub repository.

  • Suggesting Enhancements: Have an idea for a new feature or an improvement? Let us know by creating an issue.

  • Submitting Pull Requests: We are happy to review and merge pull requests. Before making significant changes, please open an issue first to discuss your ideas.

The source code is open-sourced on GitHub.

👥 Community & Support

📝 License

Licensed under the Apache 2.0 License.

Available Tools

5 tools
component-builderB

Retrieve documentation for all filtered components and charts to prepare for component generation, This tool ONLY returns the text snippet for that UI component. After calling this tool, you must edit or add files to integrate the snippet into the codebase.

ParametersJSON Schema
NameRequiredDescriptionDefault
iconNoicon module of the componentlucide
componentsYescomponents from components-filter tool
chartsYescharts from components-filter tool

TDQS

B3/5.0
Behavior2/5

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 states the tool retrieves documentation and returns text snippets, but it doesn't disclose critical behavioral traits such as whether this is a read-only operation, potential rate limits, authentication needs, error handling, or what happens if inputs are invalid. The description adds some context about the output being 'text snippets' and the need for subsequent integration, but significant gaps remain for a tool with no annotation coverage.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences and front-loaded with the main purpose, but it includes redundant phrasing ('Retrieve documentation for all filtered components and charts to prepare for component generation, This tool ONLY returns the text snippet for that UI component') that could be more concise. The second sentence adds workflow guidance, which is useful but not strictly necessary for the tool's core function. Overall, it's adequately structured but could be tighter.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the complexity (3 parameters, no annotations, no output schema), the description is incomplete. It lacks details on behavioral traits, error handling, and the format or content of the returned text snippets. While it mentions the tool's role in a workflow, it doesn't provide enough context for an AI agent to fully understand how to use it effectively, especially with no output schema to clarify return values.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

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 (icon, components, charts) with descriptions and enums. The description doesn't add any meaningful semantic details beyond what the schema provides, such as explaining the relationship between components and charts or how the icon parameter affects the output. Baseline 3 is appropriate when the schema does the heavy lifting.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: 'Retrieve documentation for all filtered components and charts to prepare for component generation.' It specifies the verb ('retrieve'), resource ('documentation for components and charts'), and context ('prepare for component generation'). However, it doesn't explicitly differentiate from sibling tools like 'component-usage-doc' or 'components-filter', which likely have related purposes.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage by stating 'This tool ONLY returns the text snippet for that UI component' and 'After calling this tool, you must edit or add files to integrate the snippet into the codebase,' which suggests it's part of a workflow. However, it doesn't explicitly state when to use this tool versus alternatives like 'component-usage-doc' or 'components-filter,' nor does it provide clear prerequisites or exclusions. The guidance is implied but not comprehensive.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

component-quality-checkB

Automatically check Vue component quality and provide detailed feedback. Use this tool when you need to validate component quality, accessibility, performance, and best practices compliance. or when mentions /check.

ParametersJSON Schema
NameRequiredDescriptionDefault
componentCodeYescode of the component from component-builder tool

TDQS

B3.3/5.0
Behavior2/5

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. While it mentions the tool provides 'detailed feedback,' it doesn't describe the format, depth, or limitations of that feedback (e.g., is it a report, score, or list of issues?). For a quality-check tool with no annotation coverage, this leaves significant gaps in understanding its behavior.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is appropriately concise with two sentences that directly address purpose and usage. The first sentence clearly states what the tool does, and the second provides usage guidelines. There's no wasted text, though the 'or when mentions /check' could be integrated more smoothly.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the complexity of a quality-check tool with no annotations and no output schema, the description is incomplete. It doesn't explain what the feedback looks like (e.g., format, structure, or examples), which is critical for understanding the tool's output. This gap makes it harder for an AI agent to use the tool effectively.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema description coverage is 100%, with the single parameter 'componentCode' fully documented in the schema. The description doesn't add any additional meaning or context about the parameter beyond what's in the schema, so it meets the baseline of 3 where the schema does the heavy lifting.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: 'Automatically check Vue component quality and provide detailed feedback.' It specifies the verb ('check'), resource ('Vue component quality'), and scope of feedback (quality, accessibility, performance, best practices). However, it doesn't explicitly differentiate from sibling tools like 'component-builder' or 'component-usage-doc' beyond mentioning component-builder in the parameter description.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides clear usage guidance: 'Use this tool when you need to validate component quality, accessibility, performance, and best practices compliance. or when mentions /check.' It specifies when to use the tool and includes a trigger ('mentions /check'), but doesn't explicitly state when not to use it or name alternatives among sibling tools.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

components-filterC

filter components with shadcn/ui components and tailwindcss, Use this tool when mentions /filter

ParametersJSON Schema
NameRequiredDescriptionDefault
messageYesrequirement json from requirement-structuring tool

TDQS

C2.6/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries full burden. It mentions 'filter components' but doesn't disclose behavioral traits like whether this is a read-only operation, what happens to filtered results (e.g., returned, modified, deleted), authentication needs, rate limits, or error conditions. The description lacks essential context for safe and effective use.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is brief with two sentences, front-loading the purpose and then usage guidance. There's no wasted text, but it could be more structured (e.g., separating purpose from usage more clearly). It's appropriately sized for a simple tool, though slightly terse.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

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 a single parameter with good schema coverage, the description is incomplete. It doesn't explain what the tool returns, how filtering works, or the relationship with sibling tools like 'requirement-structuring'. For a tool with implied complexity (filtering components with specific technologies), more context is needed to guide effective use.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100% with one parameter ('message') documented as 'requirement json from requirement-structuring tool'. The description adds no parameter information beyond what the schema provides. With high schema coverage, the baseline is 3, but the description doesn't compensate with additional context about parameter format or usage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose2/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states 'filter components with shadcn/ui components and tailwindcss' which provides some purpose (filtering components) but is vague about what 'filter' means operationally. It doesn't specify what resource is being filtered (components from where?) or distinguish from sibling tools like 'component-builder' or 'component-quality-check'. The description partially restates the name 'filter' without adding clear differentiation.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description includes 'Use this tool when mentions /filter' which provides implied usage context based on a trigger phrase. However, it doesn't explicitly state when NOT to use this tool, what alternatives exist among the sibling tools, or clarify prerequisites. The guidance is minimal and relies on pattern matching rather than functional differentiation.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

component-usage-docC

read usage doc of a component， Use this tool when mentions /doc.

ParametersJSON Schema
NameRequiredDescriptionDefault
typeYestype of the component
nameYesname of the component in lowercase

TDQS

C2.6/5.0
Behavior2/5

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 disclosure. It implies a read-only operation ('read usage doc'), but doesn't specify what the output contains (e.g., documentation text, links, examples), whether it requires authentication, or if there are rate limits. For a tool with no annotations, this leaves significant behavioral gaps, though it correctly indicates a read action.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is very concise with two short phrases, making it easy to parse. However, the second phrase 'Use this tool when mentions /doc' is somewhat cryptic and could be clearer. Overall, it's front-loaded with the core purpose and wastes no words, earning a high score for efficiency despite minor clarity issues.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no annotations and no output schema, the description is incomplete. It doesn't explain what the tool returns (e.g., documentation content, format, or errors), which is critical for a read operation. With 2 parameters fully covered by the schema, the main gap is output behavior, making this inadequate for agent use without additional context.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, with clear descriptions for both parameters ('type' with enum values and 'name' as component name in lowercase). The description adds no parameter-specific information beyond what the schema provides, such as examples or usage tips. Given high schema coverage, the baseline score of 3 is appropriate as the schema handles the heavy lifting.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose3/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states 'read usage doc of a component' which provides a clear verb ('read') and resource ('usage doc of a component'), establishing the basic purpose. However, it doesn't distinguish this tool from potential siblings like 'component-quality-check' or 'requirement-structuring' that might also involve documentation or component analysis. The purpose is clear but lacks sibling differentiation.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description includes 'Use this tool when mentions /doc', which gives a specific trigger but no broader context. It doesn't explain when to use this versus alternatives (e.g., 'component-quality-check' for quality issues or 'requirement-structuring' for requirements), nor does it provide exclusions or prerequisites. This is minimal guidance that doesn't help the agent choose between sibling tools.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

requirement-structuringA

analyze the user's natural language and structure the requirements into a clear and structured component requirement document. Use this tool when the user requests a new UI component—e.g., mentions /ui, or asks for a button, input, dialog, table, form, banner, card, or other Vue component

ParametersJSON Schema
NameRequiredDescriptionDefault
messageYesContent about user requirement in specific contextual information

TDQS

A4/5.0
Behavior3/5

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 describes the transformation behavior (natural language to structured document) but lacks details about output format, processing limitations, error handling, or performance characteristics. The description adds value by explaining the transformation but doesn't provide comprehensive 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.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is appropriately sized with two sentences that each serve distinct purposes: the first explains the tool's function, the second provides usage guidelines. It's front-loaded with the core purpose. Minor improvement could be made by slightly tightening the example list.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a single-parameter tool with no annotations and no output schema, the description provides adequate purpose and usage context but lacks details about the output format, processing behavior, or limitations. Given the transformation nature of the tool and absence of output schema, more information about what the structured document looks like would be helpful.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

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 single 'message' parameter. The description adds context about what the parameter should contain ('user's natural language', 'user requirement in specific contextual information'), but doesn't provide additional syntax, format, or constraints beyond what the schema indicates.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose with specific verbs ('analyze', 'structure') and resource ('requirements into a clear and structured component requirement document'). It distinguishes from siblings by focusing on requirement analysis rather than building, checking, filtering, or documenting components.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly states when to use this tool: 'when the user requests a new UI component' and provides concrete examples (mentions of /ui, button, input, dialog, etc.). It implicitly distinguishes from siblings by focusing on requirement structuring rather than other component-related tasks.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

  1. 5 tool updates
    • First observedcomponent-builder
    • First observedcomponent-quality-check
    • First observedcomponent-usage-doc
    • First observedcomponents-filter
    • First observedrequirement-structuring
Deploy Server
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

B3.3/5.0

Scored across 5 tools

Disambiguation4/5

Most tools have distinct purposes: component-builder retrieves documentation, component-quality-check validates quality, components-filter filters components, component-usage-doc reads usage documentation, and requirement-structuring analyzes user requirements. However, component-builder and component-usage-doc both involve documentation retrieval, which could cause some confusion, though their specific focuses differ (builder for generation prep vs. doc for usage details).

Naming Consistency4/5

The naming follows a consistent pattern with a 'component-' prefix for four tools and a 'requirement-' prefix for one, all using kebab-case. While this is mostly consistent, the deviation with 'requirement-structuring' breaks the 'component-' pattern, though it still maintains readability and a clear verb-noun structure.

Tool Count5/5

With 5 tools, the count is well-scoped for a server focused on shadcn-vue component management. Each tool serves a specific role in the component lifecycle, from requirement analysis to quality checking, without being overly sparse or bloated, fitting typical MCP server ranges.

Completeness4/5

The tool set covers key aspects of component handling: requirement analysis, documentation retrieval, filtering, quality checking, and usage documentation. However, there are minor gaps, such as no explicit tools for generating or updating components directly (component-builder only retrieves docs), which agents might need to work around by integrating with other systems.

Maintenance

ActivityInactive
ResponsivenessUnresponsive

Resources

Related MCP Connectors

Related MCP Servers

Appeared in Searches