Skip to main content
Glama
enesjakozh
idcdev

MCP Magic UI

by idcdev
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

MCPマジックUI

magicuidesign/magicuiリポジトリから Magic UI コンポーネントにアクセスして探索するための MCP (Model Context Protocol) サーバー。

MCP Magic UI とは何ですか?

MCP Magic UIは、Model Context Protocol（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