Skip to main content
Glama
favurr

shadcn-mcp-server

by favurr
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

Shadcn MCP Server

A containerized Model Context Protocol (MCP) server that enables AI agents to dynamically install shadcn UI components into a mounted project workspace.

Features

  • Standardized MCP Interface: Exposes an add_shadcn_component tool to add shadcn components.

  • Dockerized Execution: Run within a clean Docker environment, shielding host dependencies.

  • Seamless Volume Mounting: Configured to run npx shadcn@latest add directly inside the mounted host codebase.

  • Automated Registry Publishing: Automatically tags and pushes Docker images to GitHub Container Registry (GHCR) via GitHub Actions.

Related MCP server: Shadcn Space MCP

Getting Started

Usage in Docker MCP Toolkit

If your server is published to GitHub Container Registry, users can add it to their local IDE workspace with these steps:

  1. Create a local profile:

    docker mcp profile create --name my-project

  2. Add the MCP server:

    docker mcp profile server add my-project --server docker://ghcr.io/your-github-username/shadcn-mcp:latest

  3. Configure the workspace mount directory:

    docker mcp profile config my-project --set shadcn-mcp.volumes=".:/workspace"

  4. Connect the profile to your IDE (VS Code):

    docker mcp client connect vscode --profile my-project

Local Development

  1. Install dependencies:

    npm install

  2. Build TypeScript:

    npm run build

  3. Start the server:

    npm start

Available Tools

1 tool
add_shadcn_componentC

Adds a shadcn component to the project workspace.

ParametersJSON Schema
NameRequiredDescriptionDefault
componentNameYesThe name of the shadcn component to install (e.g., button, dialog).

TDQS

C2.9/5.0
Behavior2/5

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 file system changes, dependency installation, or network access required. The agent is left uninformed about 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.

Conciseness5/5

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

Single sentence with no wasted words. Front-loaded with essential information.

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 output schema, the description should at least hint at return values or success/failure behavior. It lacks completeness for a tool that likely produces side effects.

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 coverage is 100% with a clear description of the parameter. The tool description does not add any further meaning beyond the schema, so baseline score of 3 is appropriate.

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?

Description clearly states the action (adds) and resource (shadcn component) with scope (project workspace). It is specific and distinguishable from hypothetical siblings, but no siblings exist to differentiate further.

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?

No guidance on when to use this tool or prerequisites. For example, the user might need to have shadcn initialized in the project, but this is not mentioned.

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. 1 tool updatev1.0.0
    • First observedadd_shadcn_component
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.2/5.0

Scored across 1 tool

Disambiguation5/5

Only one tool exists, so there is no risk of confusion between tools. Disambiguation is perfect.

Naming Consistency5/5

The single tool name follows a clear verb_noun pattern (add_shadcn_component) in snake_case, which is consistent and descriptive.

Tool Count3/5

With only one tool, the server feels thin for a component management server. While the core operation is covered, additional tools for listing or removing components might be expected.

Completeness2/5

The server only supports adding a component, missing obvious operations like listing available components or removing them. This limits the agent's ability to manage shadcn components effectively.

Maintenance

ActivityMaintained
ResponsivenessSyncing

Resources

Related MCP Connectors

Related MCP Servers