Skip to main content
Glama

MCP 매직 UI

magicuidesign/magicui 저장소에서 Magic UI 구성 요소에 액세스하고 탐색하기 위한 MCP(모델 컨텍스트 프로토콜) 서버입니다.

MCP Magic UI란 무엇인가요?

MCP Magic UI는 Magic UI 구성 요소에 대한 액세스를 제공하기 위해 모델 컨텍스트 프로토콜(MCP)을 구현하는 서버입니다. 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를 사용할 수 없는 경우 모의 데이터가 제공됩니다.

설치

지엑스피1

구성

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 전송을 사용하여 서버에 연결할 수 있습니다.

기여하다

여러분의 참여를 환영합니다! 다음과 같은 방법으로 참여하실 수 있습니다.

  • 버그를 보고하고 문제를 생성하여 기능을 제안하세요.

  • 문서 개선

  • 버그 수정이나 새로운 기능이 포함된 풀 리퀘스트를 제출하세요

특허

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