Provides tools to list and fetch shadcn/ui components and blocks, enabling AI assistants to retrieve real-time component source code, metadata, and implementation examples directly from the official shadcn/ui repository.
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., "@shadcn MCP Server Show me the button component source code"
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 that provides AI assistants with direct access to shadcn/ui components and blocks. This server enables AI assistants like Claude (via Cursor) to fetch real-time component source code, documentation, and implementation examples.
Get started instantly without any setup:
# Run directly with npx (no installation required)
npx @magnusrodseth/shadcn-mcp-server
# Or install globally
npm install -g @magnusrodseth/shadcn-mcp-serverThen add to your Cursor configuration:
{
"mcpServers": {
"shadcn": {
"command": "npx",
"args": ["@magnusrodseth/shadcn-mcp-server"]
}
}
}Next, restart the MCP tool and your Cursor settings should look something like this:
Related MCP server: shadcn-ui MCP Server
The Shadcn MCP Server bridges the gap between AI assistants and the shadcn/ui component library. Instead of relying on potentially outdated training data, AI assistants can now fetch the latest component implementations directly from the shadcn/ui repository.
✅ Always Up-to-Date: Fetches components directly from the official shadcn/ui repository
✅ Complete Implementation: Get full source code, dependencies, and usage examples
✅ AI-Powered Development: Let AI assistants help you implement components correctly
✅ Time-Saving: No more manual copying from docs or searching for examples
sequenceDiagram
participant User as 👤 User
participant Cursor as 🖥️ Cursor/AI Assistant
participant MCP as 🔧 MCP Server
participant GitHub as 📦 shadcn/ui Repository
User->>Cursor: "Show me button component"
Cursor->>MCP: JSON-RPC Request (get_component)
MCP->>GitHub: Fetch component data via API
GitHub-->>MCP: Component source code & metadata
MCP-->>Cursor: Structured component response
Cursor->>Cursor: AI processes & formats
Cursor-->>User: Formatted component with examples
Note over MCP: Available Tools:<br/>• list_components<br/>• get_component<br/>• list_blocks<br/>• get_blockNode.js ≥ 22.0.0
pnpm (recommended) or npm
Cursor IDE (for AI integration)
Recommended: GitHub Personal Access Token (for higher rate limits)
# Clone the repository
git clone https://github.com/yourusername/shadcn-mcp-server.git
cd shadcn-mcp-server
# Install dependencies
pnpm install
# Build the project
pnpm run build# Run the setup script
node scripts/test-cursor.jsThis script will:
Generate the correct Cursor configuration
Create a wrapper script for your system
Provide step-by-step instructions
Find your Cursor settings:
macOS: ~/Library/Application Support/Cursor/User/globalStorage/cursor-settings.json
Windows: %APPDATA%\Cursor\User\globalStorage\cursor-settings.json
Linux: ~/.config/Cursor/User/globalStorage/cursor-settings.json
Add the MCP server configuration:
{
"mcpServers": {
"shadcn": {
"command": "node",
"args": ["/absolute/path/to/shadcn-mcp-server/dist/index.js"],
"env": {
"GITHUB_TOKEN": "your_github_token_here"
}
}
}
}Restart Cursor completely (quit and reopen)
Open Cursor and try these commands with Claude:
"List all available shadcn components"
"Show me the button component source code"
"Get the dashboard-01 block implementation"
"What shadcn blocks are available?"If configured correctly, Claude will fetch real-time data from the shadcn/ui repository!
# Run unit tests
pnpm test
# Test MCP server integration
pnpm run test:mcp
# Manual testing (interactive)
pnpm run test:manual# Development with hot reload
pnpm run dev
# Watch tests
pnpm run test:watch
# Clean build artifacts
pnpm run cleanTool | Description | Example Usage |
| List all available shadcn/ui components | "What shadcn components are available?" |
| Get source code and metadata for a specific component | "Show me the button component" |
| List all available shadcn/ui blocks | "What shadcn blocks can I use?" |
| Get a complete shadcn/ui block implementation | "Get the dashboard-01 block" |
User: "Show me how to create a button with different variants"
Claude with MCP: Will fetch the latest button component and provide:
Complete source code
All available variants (default, destructive, outline, secondary, ghost, link)
Size options (sm, default, lg, icon)
Usage examples with proper imports
Accessibility features
User: "I need a complete dashboard layout"
Claude with MCP: Will fetch dashboard blocks and provide:
Full implementation code
Required dependencies
Component breakdown
Styling and layout structure
User: "What new components were added to shadcn recently?"
Claude with MCP: Will fetch the current component list and highlight:
All available components
Brief descriptions
Categorization
Create a .env file in the project root:
# Optional: GitHub token for higher rate limits
GITHUB_TOKEN=ghp_your_token_here
# Optional: Enable debug logging
DEBUG=true
# Optional: Set environment
NODE_ENV=developmentGo to GitHub Settings > Developer settings > Personal access tokens
Generate a new token (classic)
No special permissions needed - public repository access is sufficient
Add the token to your environment variables
Benefits of using a token:
Higher rate limits (5,000 requests/hour vs 60/hour)
More reliable for heavy usage
Better performance
No installation required - always uses the latest version:
# No setup needed, just add to Cursor config:
{
"mcpServers": {
"shadcn": {
"command": "npx",
"args": ["@magnusrodseth/shadcn-mcp-server"],
"env": {
"GITHUB_TOKEN": "your_token_here"
}
}
}
}Benefits:
✅ Always up-to-date
✅ No global installation
✅ Works immediately
✅ No build step required
# Install once, use everywhere
npm install -g @magnusrodseth/shadcn-mcp-server
# Use in Cursor config:
{
"mcpServers": {
"shadcn": {
"command": "@magnusrodseth/shadcn-mcp-server"
}
}
}Perfect for contributing or customization:
git clone https://github.com/yourusername/shadcn-mcp-server.git
cd shadcn-mcp-server
pnpm install && pnpm run build
# Use absolute path in Cursor config:
"command": "node",
"args": ["/path/to/shadcn-mcp-server/dist/index.js"]npm install -g git+https://github.com/yourusername/shadcn-mcp-server.gitshadcn-mcp-server/
├── index.ts # Main MCP server setup
├── services/
│ └── shadcn-service.ts # Core component fetching logic
├── types/
│ └── shadcn.ts # TypeScript definitions
├── utils/
│ └── logger.ts # Logging configuration
└── scripts/
├── test-cursor.js # Cursor setup automation
└── test-mcp.js # MCP protocol testingMCP Server: Handles JSON-RPC communication with Cursor/Claude
Shadcn Service: Fetches components and blocks from GitHub API
Type Safety: Full TypeScript support for all operations
Error Handling: Graceful degradation and informative error messages
Caching: Smart caching to reduce API calls and improve performance
Verify the absolute path in your Cursor configuration
Ensure the project is built (pnpm run build)
Check that Node.js is in your system PATH
Add a GitHub token to your environment variables
The server will automatically use the token for authenticated requests
Check component name spelling (use list_components first)
Some components may have different names than expected
Restart Cursor completely (quit and reopen)
Verify JSON syntax in your Cursor configuration
Check the MCP server logs for errors
Enable detailed logging:
DEBUG=true node dist/index.jsOr set in your Cursor configuration:
{
"mcpServers": {
"shadcn": {
"command": "node",
"args": ["/path/to/dist/index.js"],
"env": {
"DEBUG": "true"
}
}
}
}Fork the repository
Create a feature branch (git checkout -b feature/amazing-feature)
Make your changes
Add tests (pnpm test)
Run the full test suite (pnpm run test:mcp)
Commit your changes (git commit -m 'Add amazing feature')
Push to the branch (git push origin feature/amazing-feature)
Open a Pull Request
Made with ❤️ for the shadcn/ui and AI development community
If this project helps you build better UIs faster, consider giving it a ⭐!
Get a complete shadcn/ui block implementation
| Name | Required | Description | Default |
|---|---|---|---|
| blockName | Yes | Name of the block (e.g., "dashboard-01", "login-form") |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations present, so description must carry behavioral burden. It only says 'complete implementation' without specifying side effects, auth needs, or what 'complete' entails (e.g., fetching all files).
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 with no unnecessary words. Front-loaded and efficient.
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 retrieval tool with one parameter and no output schema, the description is adequate but could benefit from mentioning return format or that it retrieves all files/code.
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 clear parameter description and examples. Description adds no extra meaning beyond what schema provides, so baseline 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?
Description clearly states verb ('Get') and resource ('complete shadcn/ui block implementation'), distinguishing it from siblings like get_component which targets 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 over get_component or list_blocks. No when-not-to-use or alternative suggestions provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the source code and metadata for a specific shadcn/ui component
| Name | Required | Description | Default |
|---|---|---|---|
| componentName | Yes | Name of the component (e.g., "button", "card", "input") |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and the description does not disclose behavioral traits such as whether this is a read-only operation, authentication requirements, or any side effects. It only mentions the basic purpose without adding 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?
The description is a single, straightforward sentence with no redundant words. It efficiently conveys the core functionality.
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 simplicity (one parameter, no output schema), the description is adequate but lacks details on return format or any usage constraints. It is minimally complete but leaves room for improvement in providing 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?
Schema coverage is 100% with a clear parameter description for 'componentName'. However, the tool description does not add any additional semantic meaning beyond what the schema already provides, resulting in minimal added value.
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 ('Get'), the resource ('source code and metadata'), and the specific context ('shadcn/ui component'). It distinguishes from sibling tools like 'get_block' which targets a different resource.
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 like 'list_components' or 'get_block'. The description only states what it does, without specifying use cases or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all available shadcn/ui blocks
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Minimal but adequate: 'list' implies a read-only, safe operation. Lacks details on pagination or return format, but for a no-parameter tool this is acceptable.
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 fluff. Front-loaded verb and resource. Every word 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?
Given no parameters or output schema, the description sufficiently explains the tool's purpose. Lacks mention of return type but siblings imply block objects.
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?
No parameters exist; baseline score per rule (0 params = baseline 4). No need to add parameter info.
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 'List' and resource 'all available shadcn/ui blocks', clearly distinguishing from sibling tools like get_block (single block) and list_components (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 explicit guidance on when to use vs alternatives, but the simple description implies usage for retrieving all blocks. Missing when-not or alternative recommendations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all available shadcn/ui components
| Name | Required | Description | Default |
|---|---|---|---|
| category | No | Optional category filter |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description only states the basic action. It does not disclose pagination, output format, or any side effects. A read operation is implied but not explicitly confirmed.
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 gets straight to the point. It could be slightly improved by mentioning the optional filter, but it is efficient.
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?
The tool has one optional parameter and no output schema. The description covers the main purpose but does not explain what the returned list contains or any limitations. It is minimally adequate.
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% for the single parameter 'category', which has a clear description 'Optional category filter'. The tool description adds no additional 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?
The description clearly specifies listing all available shadcn/ui components, distinguishing it from siblings like get_component (single component) and list_blocks (blocks). However, it does not mention the optional category filter, creating a slight inconsistency with 'all'.
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. The description does not indicate that category filtering is available or when to use get_component or list_blocks instead.
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.
v1.1.2get_blockget_componentlist_blockslist_componentsEach tool has a unique purpose: listing vs getting, and blocks vs components. No overlap, clear boundaries.
All tools follow a consistent verb_noun pattern (get/list + block/component) with underscores, no style mixing.
4 tools are well-scoped for a reference server on shadcn/ui components and blocks, neither too few nor too many.
The set covers both listing and retrieving individual items for both blocks and components, meeting typical informational needs without obvious gaps.
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.
Community library of composable AI prompt blocks for search, composition, and contribution.
Serves your design system and coding standards to coding agents, so they stop guessing.
Generate, inspect, and manage Flowstep UI designs directly from your AI assistant.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/magnusrodseth/shadcn-mcp-server'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
