Skip to main content
Glama
enesjakozh
idcdev

MCP Magic UI

by idcdev
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

MCP 魔法用户界面

用于从magicuidesign/magicui存储库访问和探索 Magic UI 组件的 MCP（模型上下文协议）服务器。

什么是 MCP Magic UI？

MCP Magic UI 是一个实现模型上下文协议 (MCP) 的服务器，用于提供对 Magic UI 组件的访问。它从 Magic UI GitHub 代码库中获取组件数据，对其进行分类，并通过 MCP API 提供。这使得 AI 助手和其他 MCP 客户端能够轻松地在其应用程序中发现并使用 Magic UI 组件。

Related MCP server: Magic UI MCP Server

特征

  • 组件发现：通过 MCP 工具访问所有 Magic UI 组件

  • 组件分类：组件根据其名称和依赖关系自动分类

  • 缓存系统：组件数据的本地缓存，以减少 GitHub API 调用并离线工作

  • 多种传输选项：支持 stdio 和 HTTP 传输方法

  • 回退机制：当 GitHub API 不可用时提供模拟数据

安装

# 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

配置

为了避免 GitHub API 速率限制，建议设置 GitHub 个人访问令牌：

  1. 在https://github.com/settings/tokens创建令牌

  2. 在项目根目录中创建一个.env文件（或从.env.example复制）

  3. 将您的令牌添加到.env文件：

GITHUB_TOKEN=your_github_token_here

用法

启动服务器

您可以使用 stdio 或 HTTP 传输启动服务器：

# Using stdio transport (default)
npm start

# Using HTTP transport
TRANSPORT_TYPE=http npm start

连接到服务器

您可以使用任何 MCP 客户端连接到服务器。例如，使用 MCP Inspector：

npx @modelcontextprotocol/inspector mcp-magic-ui

或者，如果使用 HTTP 传输：

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

可用工具

该服务器提供以下 MCP 工具：

  • get_all_components - 获取所有可用 Magic UI 组件及其元数据的列表

  • get_component_by_path - 通过文件路径获取特定组件的源代码

项目结构

  • src/ ——源代码

    • index.ts - 服务器的主入口点

    • cli.ts命令行界面

    • server.ts - MCP 服务器配置和工具定义

    • services/ -服务模块

      • github.ts ——GitHub API 交互和缓存

      • component-parser.ts - 组件分类和处理

  • cache/ - 组件数据的本地缓存

  • dist/ ——编译后的 JavaScript 代码

工作原理

  1. 服务器从 Magic UI GitHub 存储库获取组件数据

  2. 组件数据在本地缓存，以减少 API 调用并支持离线使用

  3. 组件根据其名称和依赖关系进行分类

  4. 服务器公开 MCP 工具来访问和搜索组件

  5. 客户端可以使用 stdio 或 HTTP 传输连接到服务器

贡献

欢迎贡献！以下是一些您可以贡献的方式：

  • 通过创建问题来报告错误并建议功能

  • 改进文档

  • 提交包含错误修复或新功能的拉取请求

执照

麻省理工学院

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
Deploy Server
Shareable, User-Owned Context BackendPeople, applications, and agents read, write, and coordinate together in one context lake. Reach it over MCP, a CLI, a Python SDK, or REST.fulcradynamics.comAd

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

Resources

Related MCP Connectors

Related MCP Servers

Appeared in Searches