Skip to main content
Glama
vparsatwar-git

21st.dev Magic AI Agent

by vparsatwar-git
OverviewSchemaRelated ServersScoreDiscussions
TypeScript
Local

21st.dev Magic AI Agent

MCP Banner

Magic Component Platform (MCP) is a powerful AI-driven tool that helps developers create beautiful, modern UI components instantly through natural language descriptions. It integrates seamlessly with popular IDEs and provides a streamlined workflow for UI development.

🌟 Features

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

  • Multi-IDE Support:

  • Modern Component Library: Access to a vast collection of pre-built, customizable components inspired by 21st.dev

  • Real-time Preview: Instantly see your components as you create them

  • TypeScript Support: Full TypeScript support for type-safe development

  • SVGL Integration: Access to a vast collection of professional brand assets and logos

  • Component Enhancement: Improve existing components with advanced features and animations (Coming Soon)

Related MCP server: Magic Component Platform

🎯 How It Works

  1. Tell Agent What You Need

    • In your AI Agent's chat, just type /ui and describe the component you're looking for

    • Example: /ui create a modern navigation bar with responsive design

  2. Let Magic Create It

    • Your IDE prompts you to use Magic

    • Magic instantly builds a polished UI component

    • Components are inspired by 21st.dev's library

  3. Seamless Integration

    • Components are automatically added to your project

    • Start using your new UI components right away

    • All components are fully customizable

🚀 Getting Started

Prerequisites

  • Node.js (Latest LTS version recommended)

  • One of the supported IDEs:

    • Cursor

    • Windsurf

    • VSCode (with Cline extension)

Installation

  1. Generate API Key

  2. Choose Installation Method

Method 1: CLI Installation (Recommended)

One command to install and configure MCP for your IDE:

npx @21st-dev/cli@latest install <client> --api-key <key>

Supported clients: cursor, windsurf, cline, claude

Method 2: Manual Configuration

If you prefer manual setup, add this to your IDE's MCP config file:

{
  "mcpServers": {
    "@21st-dev/magic": {
      "command": "npx",
      "args": ["-y", "@21st-dev/magic@latest", "API_KEY=\"your-api-key\""]
    }
  }
}

Config file locations:

  • Cursor: ~/.cursor/mcp.json

  • Windsurf: ~/.codeium/windsurf/mcp_config.json

  • Cline: ~/.cline/mcp_config.json

  • Claude: ~/.claude/mcp_config.json

Method 3: VS Code Installation

For one-click installation, click one of the install buttons below:

Install with NPX in VS Code Install with NPX in VS Code Insiders

Manual VS Code Setup

First, check the install buttons above for one-click installation. For manual setup:

Add the following JSON block to your User Settings (JSON) file in VS Code. You can do this by pressing Ctrl + Shift + P and typing Preferences: Open User Settings (JSON):

{
  "mcp": {
    "inputs": [
      {
        "type": "promptString",
        "id": "apiKey",
        "description": "21st.dev Magic API Key",
        "password": true
      }
    ],
    "servers": {
      "@21st-dev/magic": {
        "command": "npx",
        "args": ["-y", "@21st-dev/magic@latest"],
        "env": {
          "API_KEY": "${input:apiKey}"
        }
      }
    }
  }
}

Optionally, you can add it to a file called .vscode/mcp.json in your workspace:

{
  "inputs": [
    {
      "type": "promptString",
      "id": "apiKey",
      "description": "21st.dev Magic API Key",
      "password": true
    }
  ],
  "servers": {
    "@21st-dev/magic": {
      "command": "npx",
      "args": ["-y", "@21st-dev/magic@latest"],
      "env": {
        "API_KEY": "${input:apiKey}"
      }
    }
  }
}

❓ FAQ

How does Magic AI Agent handle my codebase?

Magic AI Agent only writes or modifies files related to the components it generates. It follows your project's code style and structure, and integrates seamlessly with your existing codebase without affecting other parts of your application.

Can I customize the generated components?

Yes! All generated components are fully editable and come with well-structured code. You can modify the styling, functionality, and behavior just like any other React component in your codebase.

What happens if I run out of generations?

If you exceed your monthly generation limit, you'll be prompted to upgrade your plan. You can upgrade at any time to continue generating components. Your existing components will remain fully functional.

How soon do new components get added to 21st.dev's library?

Authors can publish components to 21st.dev at any time, and Magic Agent will have immediate access to them. This means you'll always have access to the latest components and design patterns from the community.

Is there a limit to component complexity?

Magic AI Agent can handle components of varying complexity, from simple buttons to complex interactive forms. However, for best results, we recommend breaking down very complex UIs into smaller, manageable components.

🛠️ Development

Project Structure

mcp/
├── app/
│   └── components/     # Core UI components
├── types/             # TypeScript type definitions
├── lib/              # Utility functions
└── public/           # Static assets

Key Components

  • IdeInstructions: Setup instructions for different IDEs

  • ApiKeySection: API key management interface

  • WelcomeOnboarding: Onboarding flow for new users

🤝 Contributing

We welcome contributions! Please join our Discord community and provide feedback to help improve Magic Agent. The source code is available on GitHub.

👥 Community & Support

⚠️ Beta Notice

Magic Agent is currently in beta. All features are free during this period. We appreciate your feedback and patience as we continue to improve the platform.

📝 License

MIT License

🙏 Acknowledgments

  • Thanks to our beta testers and community members

  • Special thanks to the Cursor, Windsurf, and Cline teams for their collaboration

  • Integration with 21st.dev for component inspiration

  • SVGL for logo and brand asset integration

For more information, join our Discord community or visit 21st.dev/magic.

Available Tools

4 tools
21st_magic_component_builderA

"Use this tool when the user requests a new UI component—e.g., mentions /ui, /21 /21st, or asks for a button, input, dialog, table, form, banner, card, or other React component. 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
messageYesFull users message
searchQueryYesGenerate a search query for 21st.dev (library for searching UI components) to find a UI component that matches the user's message. Must be a two-four words max or phrase
standaloneRequestQueryYesYou need to formulate what component user wants to create, based on his message, possbile chat histroy and a place where he makes the request.Extract additional context about what should be done to create a ui component/page based on the user's message, search query, and conversation history, files. Don't halucinate and be on point.
absolutePathToCurrentFileYesAbsolute path to the current file to which we want to apply changes
absolutePathToProjectDirectoryYesAbsolute path to the project root directory

TDQS

A4.2/5.0
Behavior4/5

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

With no annotations, the description appropriately carries the behavioral burden. It clearly discloses that the tool only returns a snippet and does not modify files, and it sets the post-call expectation to edit/add files. This is key behavioral context, though it omits details like failure modes 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.

Conciseness5/5

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

The description is three sentences, each serving a distinct purpose: when to use, what it returns, and the required follow-up. It is front-loaded with the trigger conditions and contains no fluff or redundant information.

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

Completeness4/5

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

The description adequately covers the tool's purpose, output scope, and the agent's next steps, which is sufficient for selecting and invoking it. It could be improved by explicitly contrasting with sibling tools or describing the snippet's format, but the provided context satisfies the core requirements.

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% (all five parameters have detailed descriptions). The tool description itself adds no parameter-specific meaning, but the baseline of 3 is sufficient because the schema already documents each parameter thoroughly, including concise search query constraints and extraction instructions.

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 function: it returns a text snippet for a requested UI component. It provides specific trigger examples (e.g., '/ui', button, dialog) and explicitly notes the tool 'ONLY returns the text snippet', distinguishing it from sibling tools that likely handle inspiration or refinement.

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 gives explicit when-to-use guidance with concrete examples of user requests. It also implies exclusions via 'ONLY returns the text snippet' and instructs that file integration must happen afterward. However, it does not explicitly name alternatives or state when not to use this tool.

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

21st_magic_component_inspirationA

"Use this tool when the user wants to see component, get inspiration, or /21st fetch data and previews from 21st.dev. This tool returns the JSON data of matching components without generating new code. 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
messageYesFull users message
searchQueryYesSearch query for 21st.dev (library for searching UI components) to find a UI component that matches the user's message. Must be a two-four words max or phrase

TDQS

A3.8/5.0
Behavior3/5

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

With no annotations, the description carries the full burden for behavioral disclosure. It states the tool only returns a text snippet, does not generate code, and requires manual integration afterward. However, it is internally inconsistent about 'previews' vs 'only returns the text snippet', and it does not mention no-match behavior, authentication, or data source limitations.

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 reasonably compact but contains redundancy: 'returns the JSON data' vs 'ONLY returns the text snippet' overlap, and the phrase 'or /21st fetch data' is awkward. The final sentence about post-call integration is valuable. Overall, it could be tightened without losing substance.

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

Completeness4/5

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

Given the lack of an output schema and annotations, the description covers the tool's purpose, return type, and required follow-up action. It misses a cleaner distinction between 'data/previews' and 'text snippet' and does not mention alternative tools by name, but it is still sufficiently complete for an agent to select and use the tool correctly.

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 input schema already provides 100% coverage with clear descriptions for both parameters. The description does not add additional parameter-level semantics beyond what the schema provides, so the baseline score of 3 applies.

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 identifies the tool as a retrieval/inspiration tool for 21st.dev components, explicitly stating it returns JSON/text snippet data and does not generate code. This distinguishes it from sibling tools like the builder, which likely generates components.

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 first sentence gives explicit triggers ('when the user wants to see component, get inspiration, or /21st fetch data'), and the phrase 'without generating new code' provides an exclusion for code-generation use cases. However, it does not name alternative sibling tools explicitly, so it stops short of a full when-not/alternative matrix.

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

21st_magic_component_refinerA

"Use this tool when the user requests to re-design/refine/improve current UI component with /ui or /21 commands, or when context is about improving, or refining UI for a React component or molecule (NOT for big pages). This tool improves UI of components and returns redesigned version of the component and instructions on how to implement it."

ParametersJSON Schema
NameRequiredDescriptionDefault
contextYesExtract the specific UI elements and aspects that need improvement based on user messages, code, and conversation history. Identify exactly which components (buttons, forms, modals, etc.) the user is referring to and what aspects (styling, layout, responsiveness, etc.) they want to enhance. Do not include generic improvements - focus only on what the user explicitly mentions or what can be reasonably inferred from the available context. If nothing specific is mentioned or you cannot determine what needs improvement, return an empty string.
userMessageYesFull user's message about UI refinement
absolutePathToRefiningFileYesAbsolute path to the file that needs to be refined

TDQS

A4/5.0
Behavior3/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It does mention that the tool returns a redesigned version and implementation instructions, which gives some output behavior. However, it does not disclose whether the tool modifies the file (write), requires specific permissions, or has any side effects. This ambiguity could mislead the agent about the tool's mutability.

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?

The description is two sentences, front-loaded with an explicit usage directive, and every sentence earns its place. It is concise without redundancy, efficiently conveying purpose, usage, and output.

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

Completeness4/5

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

The description covers the tool's purpose, when to use it, and what it returns (redesigned version + instructions), which is essential for a tool with no output schema. It leverages the schema's rich parameter descriptions. However, the lack of side-effect transparency and absence of annotations leave a small gap in complete understanding of the tool's behavior.

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%, and each parameter has a detailed description, especially 'context' which explains what to extract and what to do if nothing specific is mentioned. Since the schema fully documents parameters, the description adds no extra semantics, but the schema already provides sufficient meaning.

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 states a specific verb+resource: 'improves UI of components and returns redesigned version of the component and instructions on how to implement it.' It distinguishes from siblings by specifying it is for refining existing components (not building) and excludes big pages, which aligns with the tool name and differentiates it from 21st_magic_component_builder.

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?

It clearly says when to use: when the user requests to re-design/refine/improve a current UI component with /ui or /21 commands, or when context is about improving/refining a React component/molecule. It also excludes big pages. However, it does not explicitly name alternatives (e.g., 'use builder for new components'), so it lacks full explicit alternative guidance.

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. Dates show when Glama detected each change.

  1. 4 tool updatesv0.1.1-beta.1
    • First observed21st_magic_component_builder
    • First observed21st_magic_component_inspiration
    • First observed21st_magic_component_refiner
    • First observedlogo_search
Install Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.9/5.0
Disambiguation3/5

The three 21st_magic_component tools have distinct purposes (build, inspire, refine), but the inspiration tool's description contains contradictory text about returning a text snippet, which could confuse agents into thinking it overlaps with the builder. Logo search is clearly separate, but the overlap between builder and inspiration creates some ambiguity.

Naming Consistency3/5

Three tools follow a consistent 21st_magic_component_ prefix pattern, while logo_search deviates entirely, resulting in a mixed naming convention. All names are snake_case and readable, but the lack of a unified prefix makes the set feel somewhat inconsistent.

Tool Count5/5

Four tools is a well-scoped size for a UI component agent, covering creation, refinement, inspiration, and logo lookup without unnecessary bloat. This fits comfortably within the typical 3-15 tool range and each tool has a clear role.

Completeness4/5

The tool surface covers the essential lifecycle for UI component work: create new components, refine existing ones, find inspiration, and search logos. Minor gaps exist, such as no explicit component analysis or listing tool, but agents can work around these without major failures.

Maintenance

ActivityInactive
ResponsivenessSyncing

Resources

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Related MCP Servers

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/vparsatwar-git/magic-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server