Skip to main content
Glama

Interfaz de usuario mágica de MCP

Un servidor MCP (Protocolo de contexto de modelo) para acceder y explorar los componentes de Magic UI desde el repositorio magicuidesign/magicui .

¿Qué es MCP Magic UI?

MCP Magic UI es un servidor que implementa el Protocolo de Contexto de Modelo (MCP) para proporcionar acceso a los componentes de Magic UI. Obtiene datos de los componentes del repositorio de GitHub de Magic UI, los categoriza y los publica mediante una API de MCP. Esto permite a los asistentes de IA y otros clientes de MCP descubrir y usar fácilmente los componentes de Magic UI en sus aplicaciones.

Related MCP server: Magic UI MCP Server

Características

  • Descubrimiento de componentes : acceda a todos los componentes de Magic UI a través de las herramientas MCP

  • Categorización de componentes : los componentes se categorizan automáticamente según sus nombres y dependencias.

  • Sistema de almacenamiento en caché : almacenamiento en caché local de datos de componentes para reducir las llamadas a la API de GitHub y trabajar sin conexión

  • Múltiples opciones de transporte : compatibilidad con métodos de transporte stdio y HTTP

  • Mecanismo de respaldo : se proporcionan datos simulados cuando la API de GitHub no está disponible

Instalación

# Clone the repository
git clone https://github.com/idcdev/mcp-magic-ui.git
cd mcp-magic-ui

# Install dependencies
npm install

# Build the project
npm run build

Configuración

Para evitar los límites de velocidad de la API de GitHub, se recomienda configurar un token de acceso personal de GitHub:

  1. Crea un token en https://github.com/settings/tokens

  2. Cree un archivo .env en la raíz del proyecto (o cópielo desde .env.example )

  3. Añade tu token al archivo .env :

GITHUB_TOKEN=your_github_token_here

Uso

Iniciando el servidor

Puede iniciar el servidor utilizando el transporte stdio o HTTP:

# Using stdio transport (default)
npm start

# Using HTTP transport
TRANSPORT_TYPE=http npm start

Conectando al servidor

Puede conectarse al servidor mediante cualquier cliente MCP. Por ejemplo, con el Inspector MCP:

npx @modelcontextprotocol/inspector mcp-magic-ui

O, si utiliza el transporte HTTP:

npx @modelcontextprotocol/inspector http://localhost:3000

Herramientas disponibles

El servidor proporciona las siguientes herramientas MCP:

  • get_all_components : obtiene una lista de todos los componentes de Magic UI disponibles con sus metadatos

  • get_component_by_path - Obtener el código fuente de un componente específico por su ruta de archivo

Estructura del proyecto

  • src/ - Código fuente

    • index.ts - Punto de entrada principal para el servidor

    • cli.ts - Interfaz de línea de comandos

    • server.ts : configuración del servidor MCP y definiciones de herramientas

    • services/ - Módulos de servicio

      • github.ts : interacción y almacenamiento en caché de la API de GitHub

      • component-parser.ts - Categorización y procesamiento de componentes

  • cache/ - Caché local para datos de componentes

  • dist/ - Código JavaScript compilado

Cómo funciona

  1. El servidor obtiene datos de los componentes del repositorio de GitHub de Magic UI

  2. Los datos de los componentes se almacenan en caché localmente para reducir las llamadas a la API y permitir el uso sin conexión

  3. Los componentes se clasifican según sus nombres y dependencias.

  4. El servidor expone herramientas MCP para acceder y buscar componentes

  5. Los clientes pueden conectarse al servidor mediante stdio o transporte HTTP

Contribuyendo

¡Agradecemos sus contribuciones! Aquí hay algunas maneras de contribuir:

  • Informar errores y sugerir funciones mediante la creación de problemas

  • Mejorar la documentación

  • Enviar solicitudes de extracción con correcciones de errores o nuevas funciones

Licencia

Instituto Tecnológico de Massachusetts (MIT)

Available Tools

2 tools
get_all_componentsD
ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

D1/5.0
Behavior1/5

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

Tool has no description.

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

Conciseness1/5

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

Tool has no description.

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

Completeness1/5

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

Tool has no description.

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

Parameters1/5

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

Tool has no description.

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

Purpose1/5

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

Tool has no description.

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

Usage Guidelines1/5

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

Tool has no description.

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

get_component_by_pathD
ParametersJSON Schema
NameRequiredDescriptionDefault
pathYesPath to the component file

TDQS

D1/5.0
Behavior1/5

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

Tool has no description.

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

Conciseness1/5

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

Tool has no description.

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

Completeness1/5

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

Tool has no description.

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

Parameters1/5

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

Tool has no description.

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

Purpose1/5

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

Tool has no description.

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

Usage Guidelines1/5

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

Tool has no description.

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
    • Changedget_all_components1 field changed
      • removedInput schema / additionalProperties
        Removed value: -false
  2. 2 tool updates
    • First observedget_all_components
    • First observedget_component_by_path

TDQS

D1.8/5.0

Scored across 2 tools

Disambiguation5/5

The two tools have clearly distinct purposes: one retrieves all components, while the other retrieves a specific component by path. There is no overlap or ambiguity between them, making it easy for an agent to choose the correct tool based on the need for bulk vs. targeted retrieval.

Naming Consistency5/5

Both tools follow a consistent verb_noun pattern with 'get' as the verb, and they use snake_case uniformly. The naming is predictable and readable, with no deviations in style or convention across the tool set.

Tool Count2/5

With only 2 tools, the server feels thin for a UI-related domain, as it lacks operations for creating, updating, or deleting components, which are typical in such contexts. This minimal set may not support comprehensive agent workflows effectively.

Completeness2/5

The tool surface is severely incomplete for a UI component domain, covering only retrieval operations. There are obvious gaps for CRUD/lifecycle management, such as create, update, or delete tools, which will likely cause agent failures when full component manipulation is needed.

Maintenance

ActivityInactive
ResponsivenessNo issues

Related MCP Connectors

Related MCP Servers