Skip to main content
Glama
dazeb

Component Harvester MCP Server

by dazeb
OverviewSchemaRelated ServersScoreDiscussions
JavaScript
Remote

Component Harvester MCP Server ✨

This MCP (Model Context Protocol) server is your AI agent's trusty sidekick for sourcing React components from popular UI libraries. It automates finding, fetching, and understanding how to integrate UI elements into your projects, supporting both direct code harvesting and CLI-based integration guidance.

Supported Libraries

  • Aceternity UI: Full component code and metadata harvesting.

  • Shadcn UI: Component metadata harvesting and CLI-based integration guidance.

  • (More to come soon!)

Related MCP server: shadcn MCP Server

TLDR;

This server fetches component information from Aceternity UI and Shadcn UI.

  • For Aceternity UI, it gets the full code and dependencies.

  • For Shadcn UI, it gets metadata (like dependencies, files created) and tells you how to install the component using its CLI.

The server stores this information and can generate detailed prompts for an AI agent (or you!) to integrate these components.

Example Agent Prompts:

  • "Fetch the '3D Pin' component from Aceternity UI and show me the code and dependencies."

  • "List all available components from Aceternity UI."

  • "Scan the 'Alert Dialog' component from Shadcn UI and show me how to integrate it."

  • "List all available Shadcn UI components."

What Can It Do? 🚀

The Component Harvester enables an AI agent to:

  1. Discover Components: Automatically learn about available components by fetching and parsing the main JSON registries from Aceternity UI (https://ui.aceternity.com/registry) and Shadcn UI (https://ui.shadcn.com/registry).

  2. Fetch Component Data:

    • Aceternity UI: Grabs detailed, structured JSON data for specific components (e.g., from https://ui.aceternity.com/registry/[slug].json), which includes full source code, file paths, dependencies, etc.

    • Shadcn UI: Retrieves metadata for specific components directly from its main registry JSON. This includes dependencies, file names, etc., but not the full source code (as Shadcn components are added via CLI).

  3. Store Locally:

    • Maintains a central index (data/harvested_index.json) of all processed components from all sources.

    • Stores detailed data for each component in source-specific directories:

      • data/aceternity/[slug].json: Contains the full fetched JSON (including code) for an Aceternity UI component.

      • data/shadcn/[slug].json: Stores the metadata (name, type, deps, file list) for a Shadcn UI component, as extracted from their main registry.

  4. Generate Integration Blueprints: Produces detailed, step-by-step prompts:

    • Aceternity UI Prompts: Include full code, file paths, and dependency information for manual integration.

    • Shadcn UI Prompts: Guide using npx shadcn-ui@latest add [slug], list expected files, and dependencies.

How It Works 🧙‍♂️

1. Learning the Lay of the Land: Registry Processing

When the server starts, it fetches the main registry JSON directly from both Aceternity UI and Shadcn UI.

graph TD
    subgraph Server Startup
        direction LR
        A1[Initiate] --> A2a[Fetch JSON from aceternity.com/registry]
        A2a --> A3a[Parse Aceternity JSON & Cache Slugs]
        A1 --> A2b[Fetch JSON from shadcn.com/registry]
        A2b --> A3b[Parse Shadcn JSON & Cache Metadata]
    end
    A3a --> A4[Server Ready]
    A3b --> A4

  • The Goal: To build internal maps (aceternityRegistryData and shadcnRegistryData) for quick lookups.

    • For Aceternity, it maps a normalized component name to its slug (e.g., "3D Pin" -> "3d-pin").

    • For Shadcn, it maps a normalized component name to its full metadata object from the registry.

2. The Treasure Hunt: Fetching/Processing Specific Component Data

Aceternity UI: When an agent requests an Aceternity component (e.g., "3D Pin"), the server uses its cached slug.

graph TD
    B0[Agent Request: scan_aceternity_component] --> B1[MCP Server]
    B1 --> B2{Slug in Aceternity Cache?}
    B2 -- Yes --> B3[Construct URL: aceternity.com/registry/slug.json]
    B3 --> B4[Fetch Component JSON via Axios]
    B4 -- Full JSON Data --> B5[Parse & Store Full Component Data]
    B5 --> B6[Update Main Index & In-Memory Cache]
    B6 --> B7[Report Success]
    B2 -- No --> B8[Report Not Found]

  • Data Fetched: The complete JSON for the component, including source code for all its files.

Shadcn UI: When an agent requests a Shadcn component (e.g., "Alert Dialog"):

graph TD
    C0[Agent Request: scan_shadcn_component] --> C1[MCP Server]
    C1 --> C2{Component in Shadcn Cache?}
    C2 -- Yes --> C3[Retrieve Metadata from Cache]
    C3 -- Metadata (files, deps) --> C4[Store This Metadata as Component's Data]
    C4 --> C5[Update Main Index & In-Memory Cache]
    C5 --> C6[Report Success]
    C2 -- No --> C7[Report Not Found]

  • Data Processed: The metadata (dependencies, file list, etc.) already fetched from https://ui.shadcn.com/registry. No individual [slug].json is fetched for Shadcn as it's not provided by them.

3. Keeping a Record: Component Storage

All processed component data is stored:

  1. Individual JSON Files:

    • data/aceternity/[slug].json: Stores the full JSON (code, files, deps) for an Aceternity UI component.

    • data/shadcn/[slug].json: Stores the metadata (name, type, deps, file list) for a Shadcn UI component, as extracted from their main registry.

  2. Central Index File (data/harvested_index.json): A manifest of all components from all sources, with metadata like name, source, slug, description, path to its specific JSON file, and last scan time.

    {
  "aceternity:3DPin": { /* ... metadata ... */ },
  "shadcn:AlertDialog": { /* ... metadata ... */ }
}

An in-memory cache (inMemoryIndexCache) mirrors this index for fast access.

4. The Blueprint: Generating Integration Prompts

The get_aceternity_component_prompt and get_shadcn_component_prompt tools transform stored data into integration instructions.

  • Aceternity UI Prompts: Include full code, file paths, and dependency information.

  • Shadcn UI Prompts: Guide using npx shadcn-ui@latest add [slug], list expected files, and dependencies.

Meet the Tools: MCP Server Endpoints 🛠️

Common Tools

  • list_harvested_components: Lists all components stored in the index.

    • Input: { "source": "aceternity" | "shadcn" | "all" } (optional)

Aceternity UI Tools

  • scan_aceternity_component: Fetches and stores full data for an Aceternity UI component.

    • Input: { "componentName": "string" }

  • get_aceternity_component_prompt: Generates a detailed integration guide (with code) for a scanned Aceternity UI component.

    • Input: { "componentName": "string" }

Shadcn UI Tools

  • list_shadcn_components: Lists all components available in the Shadcn UI registry cache.

    • Input: {}

  • scan_shadcn_component: Processes and stores metadata for a Shadcn UI component from its main registry.

    • Input: { "componentName": "string" }

  • get_shadcn_component_prompt: Generates an integration guide (CLI-focused) for a Shadcn UI component.

    • Input: { "componentName": "string" }

The Road Ahead: Future Enhancements 🗺️

  • Smarter Prompt Generation: More context-aware advice in prompts.

  • Broader Horizons: Adding support for more component libraries.

  • Manual Cache Refresh: Tools to re-trigger registry fetching on demand.

  • Enhanced Error Handling: Continuous improvements for robustness.

We're excited about making component integration smoother and faster!

Available Tools

6 tools
get_aceternity_component_promptB

Retrieves a harvested Aceternity component and generates a detailed integration prompt.

ParametersJSON Schema
NameRequiredDescriptionDefault
componentNameYesThe name of the component to retrieve (e.g., 'AnimatedPin').

TDQS

B3.2/5.0
Behavior2/5

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

With no annotations, the description must disclose behavioral traits. It only states 'retrieves and generates', offering no info on side effects, permissions, or error states. It does not clarify if the operation is read-only or if prior harvesting is required.

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 a single, clear sentence with no redundant words. It front-loads the action and is appropriately concise for a simple tool.

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

Completeness3/5

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

Given the tool's simplicity, the description covers the core functionality but lacks details on output format, error handling, or component availability. It is minimally adequate but leaves some gaps.

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

Parameters4/5

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

The single parameter has 100% schema coverage, and the description adds context by specifying 'harvested Aceternity component', implying a prerequisite. This adds meaning beyond the schema's basic type and example.

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

Purpose4/5

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

The description clearly states it retrieves a harvested Aceternity component and generates an integration prompt, distinguishing it from sibling tools like get_shadcn_component_prompt. However, it could be more explicit about the scope.

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

Usage Guidelines2/5

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

No guidance is provided on when to use this tool versus alternatives, nor are there any prerequisites or exclusions. The sibling tools are listed but not contrasted.

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

get_shadcn_component_promptB

Retrieves a harvested shadcn component and generates a detailed integration prompt.

ParametersJSON Schema
NameRequiredDescriptionDefault
componentNameYesThe name of the component to retrieve (e.g., 'button').

TDQS

B3.2/5.0
Behavior2/5

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

No annotations are provided, and the description does not disclose any behavioral traits such as side effects, authentication needs, or whether the component must be pre-harvested. The description is minimal for a retrieval-plus-generation tool.

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 a single sentence with 10 words, front-loaded with the key action, and contains no redundant information.

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

Completeness2/5

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

Given the tool has no output schema and no annotations, the description lacks detail on the return format or content of the integration prompt, and does not clarify that the component must already be harvested.

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?

With 100% schema coverage, the schema already defines the parameter as component name. The description adds no further meaning beyond a usage example, so it meets the baseline but does not exceed.

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 retrieves a harvested shadcn component and generates a detailed integration prompt, with specific verbs and resource. It distinguishes from siblings like get_aceternity_component_prompt by specifying 'shadcn'.

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

Usage Guidelines2/5

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

The description provides no guidance on when to use this tool versus alternatives such as list_shadcn_components or scan_shadcn_component, nor does it mention any prerequisites or exclusions.

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

list_harvested_componentsB

Lists components that have been harvested and stored.

ParametersJSON Schema
NameRequiredDescriptionDefault
sourceNoFilter components by source, or 'all'. Defaults to 'all'.

TDQS

B3.1/5.0
Behavior2/5

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

With no annotations, the description should disclose behavioral traits. It only states it 'lists' components, which implies a read operation, but does not mention any side effects, authorization needs, or default behaviors like sorting or pagination.

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 a single, short sentence with no extraneous words. Every word is necessary to convey the basic purpose.

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

Completeness3/5

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

Given the simple interface (1 parameter, no output schema), the description is minimally adequate. However, it lacks context on what 'harvested' means or what the output contains, which would help a new user understand usage.

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 covers 100% of parameters and includes a description for the only parameter 'source' (filter by source or all). The description adds no additional semantic value beyond the schema.

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

Purpose4/5

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

The description clearly states it lists harvested and stored components, which defines the subject. It distinguishes from siblings like list_shadcn_components by focusing on harvested state, but it doesn't explicitly state that it aggregates from multiple sources.

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

Usage Guidelines2/5

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

No guidance is provided on when to use this tool versus other list tools like list_shadcn_components or scan tools. There is no mention of prerequisites or appropriate contexts.

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

list_shadcn_componentsB

Lists all available shadcn UI components.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

B3.1/5.0
Behavior2/5

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

No annotations provided, so the description carries full burden. It only states the action without disclosing behavioral traits like read-only, authorization needs, or pagination.

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?

Single sentence, no waste, front-loaded verb and resource.

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

Completeness2/5

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

Despite simplicity, the description lacks information about what the list contains (e.g., component names, metadata) and does not specify output format, leaving agent partly in the dark.

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

Parameters4/5

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

No parameters exist, so baseline 4 applies. The description adds no param details, but none are needed.

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

Purpose4/5

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

The description clearly states the verb 'lists' and the resource 'shadcn UI components', but does not differentiate from sibling tools like list_harvested_components.

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

Usage Guidelines2/5

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

No guidance on when to use this tool versus alternatives; it simply states what it does without context of use cases or exclusions.

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

scan_aceternity_componentC

Scans a specific Aceternity UI component page and stores the component.

ParametersJSON Schema
NameRequiredDescriptionDefault
componentNameYesThe unique name for the component (e.g., 'AnimatedPin', '3D Pin').
componentURLNoOptional: The URL of the Aceternity UI page for the component (used as a fallback if not in registry, or for non-Aceternity sources).

TDQS

C2.9/5.0
Behavior2/5

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

Without annotations, the description should fully disclose behavioral traits. It does not explain side effects (e.g., overwriting existing components), network requirements, or storage details. The description is too minimal.

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

Conciseness4/5

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

The description is one short sentence (11 words), but it is concise and front-loaded. It could be slightly more informative without sacrificing conciseness.

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

Completeness2/5

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

Given no output schema and no annotations, the description is too brief. It does not explain the scanning process, storage behavior, or what happens when the optional URL is not provided. More context is needed for an agent to use this 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?

Schema coverage is 100%, so baseline is 3. The description adds no additional meaning beyond what the schema already provides about parameters; it only reinforces the source (Aceternity UI), which is already implicit in the tool name.

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

Purpose4/5

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

The description clearly states the tool scans an Aceternity UI component page and stores the component. The verb 'scan' is clear and distinguishes from sibling tools like 'get_aceternity_component_prompt' and 'scan_shadcn_component'.

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

Usage Guidelines2/5

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

No guidance on when to use this tool vs alternatives. No mention of prerequisites, fallback logic for optional URL, or recommendations for choosing between scanning and other tools.

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

scan_shadcn_componentB

Scans a specific shadcn UI component and stores it.

ParametersJSON Schema
NameRequiredDescriptionDefault
componentNameYesThe unique name for the component (e.g., 'button', 'card').

TDQS

B3.1/5.0
Behavior2/5

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

With no annotations, the description must disclose behavioral traits. 'Scans and stores' implies mutation but lacks details on side effects, idempotency, or whether it overwrites existing stored components.

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 a single sentence, making it concise, but it lacks structure or breakdown of behavior. It is not overly wordy, but could benefit from additional context.

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

Completeness3/5

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

Given low complexity (1 param, no output schema), the description is minimally complete. However, it does not explain return values or confirm that the component is stored successfully, leaving some gaps.

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 coverage is 100% for the single parameter componentName, so baseline is 3. The description adds no extra meaning beyond the schema's example values; it is adequate but not improved.

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 uses specific verb 'scans' and resource 'shadcn UI component', clearly indicating what the tool does. It distinguishes from sibling tool 'scan_aceternity_component' by naming shadcn specifically.

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

Usage Guidelines2/5

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

No guidance on when to use this tool versus siblings like 'get_shadcn_component_prompt' or 'scan_aceternity_component'. The description does not mention scenarios or exclusions.

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

Install Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.5/5.0
Disambiguation5/5

Each tool targets a distinct operation or component source (Aceternity vs shadcn). The list tools differentiate between all available components and those already harvested, preventing ambiguity.

Naming Consistency5/5

All tools follow a consistent verb_noun pattern (scan_, get_, list_) using snake_case, making the tool surface predictable and easy to navigate.

Tool Count5/5

6 tools is well-suited for a focused server handling two component libraries, covering scanning, retrieval with prompts, and listing without unnecessary bloat.

Completeness4/5

The tool set covers the main lifecycle (scan, list, retrieve) but lacks update or delete operations. This minor gap does not hinder the core harvesting workflow.

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/dazeb/mcp-react-component-harvester'

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