Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@AceternityUI_MCP_Server What are the available background components?"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
A Model Context Protocol (MCP) server that provides access to the Aceternity UI component library documentation and tools.
This MCP server allows AI assistants to:
Browse Aceternity UI components
Search for specific components
Get detailed component information
Access component documentation and usage examples
Related MCP server: Material UI MCP Server
npm install -g aceternity-ui-mcp-servergit clone https://github.com/yeshsurya/AceternityUI_MCP_Server.git
cd AceternityUI_MCP_Server
npm install
npm run buildIf installed globally via npm:
aceternity-ui-mcp-serverIf installed from source:
npm startOr directly:
node build/index.jsaceternity-ui-mcp-server --help # Show help
aceternity-ui-mcp-server --version # Show versionLOG_LEVEL: Set logging level (debug, info, warn, error). Default: info
Example:
LOG_LEVEL=debug npm startAdd to your Claude Desktop configuration file:
~/Library/Application Support/Claude/claude_desktop_config.json
%APPDATA%\Claude\claude_desktop_config.json
{
"mcpServers": {
"aceternity-ui": {
"command": "aceternity-ui-mcp-server"
}
}
}{
"mcpServers": {
"aceternity-ui": {
"command": "node",
"args": ["C:\\gitRepos\\aceternity_ui_mcp\\build\\index.js"]
}
}
}Note: On macOS/Linux, use forward slashes in paths. On Windows, use double backslashes.
GitHub Copilot CLI now supports MCP servers! You can add this server to your Copilot CLI configuration.
The MCP configuration file is located at:
macOS/Linux: ~/.config/mcp-config.json
Windows: %USERPROFILE%\.config\mcp-config.json
You can change this location by setting the XDG_CONFIG_HOME environment variable.
Install the server globally:
npm install -g aceternity-ui-mcp-serverOpen GitHub Copilot CLI and add the server interactively:
gh copilotUse the interactive UI to add a new MCP server:
Press the appropriate key to add a server
Fill in the server details:
Name: aceternity-ui
Command: aceternity-ui-mcp-server
Type: stdio
Press Ctrl+S to save
Edit your mcp-config.json file manually:
{
"mcpServers": {
"aceternity-ui": {
"command": "aceternity-ui-mcp-server",
"type": "stdio"
}
}
}Or if installed from source:
{
"mcpServers": {
"aceternity-ui": {
"command": "node",
"args": ["/path/to/aceternity_ui_mcp/build/index.js"],
"type": "stdio"
}
}
}After configuration, restart GitHub Copilot CLI. The Aceternity UI MCP server should now be available, and you can ask Copilot questions like:
"List all Aceternity UI background components"
"Show me the background-beams component"
"Search for animation components in Aceternity UI"
If you're using VS Code with GitHub Copilot, you can also configure MCP servers:
Open VS Code Settings (JSON)
Add the MCP server configuration:
{
"github.copilot.chat.mcp.servers": {
"aceternity-ui": {
"command": "aceternity-ui-mcp-server",
"type": "stdio"
}
}
}Restart VS Code or reload the window
Example configuration files are provided in this repository:
claude_desktop_config.example.json - Claude Desktop configuration
copilot_cli_config.example.json - GitHub Copilot CLI configuration
You can copy these files and modify them to match your installation path.
get_componentGet detailed information about a specific Aceternity UI component.
Parameters:
componentName (string, required): The slug or name of the component
Example:
{
"componentName": "background-beams"
}list_componentsList all available Aceternity UI components, optionally filtered by category.
Parameters:
category (string, optional): Filter by category (e.g., "backgrounds", "3d", "overlays")
Example:
{
"category": "backgrounds"
}search_componentsSearch for components by name, description, or tags.
Parameters:
query (string, required): Search query
Example:
{
"query": "animation"
}resource:aceternity_components - List of all available components
resource:aceternity_categories - Component categories
component_usageGet guidance on how to use a specific component.
Arguments:
componentName (required): Component name or slug
animation_guideGet recommendations for animation components.
Arguments:
useCase (required): The effect you want to achieve
background_selectorGet help choosing the right background component.
Arguments:
style (optional): Style or mood (e.g., "minimal", "dramatic")
backgrounds: Background effects and animations
3d: 3D components and effects
overlays: Modals, tooltips, and overlays
carousel: Carousels and sliders
layout: Layout components and grids
visualization: Data visualization components
aceternity_ui_mcp/
├── src/
│ ├── index.ts # Entry point and server initialization
│ ├── handler.ts # Request handlers
│ ├── resources.ts # Static resources
│ ├── prompts.ts # Prompt definitions
│ ├── data/
│ │ └── components.ts # Component data structure
│ ├── tools/
│ │ ├── index.ts # Tool registry
│ │ └── components/ # Component-related tools
│ └── utils/
│ ├── logger.ts # Logging utilities
│ ├── cache.ts # Caching layer
│ ├── circuit-breaker.ts # Circuit breaker pattern
│ ├── validation.ts # Input validation
│ └── axios.ts # HTTP client
├── build/ # Compiled JavaScript
├── package.json
└── tsconfig.jsonComprehensive Component Database: All Aceternity UI components with descriptions and metadata
Smart Search: Search by name, description, or tags
Category Filtering: Browse components by category
Caching: In-memory caching for improved performance
Circuit Breaker: Resilience pattern for external calls
Input Validation: Zod-based schema validation
Structured Logging: Winston-based logging with configurable levels
npm run buildnpm run devnpm run clean
npm run buildNode.js 18 or higher
npm or yarn
@modelcontextprotocol/sdk: MCP protocol implementation
axios: HTTP client
cheerio: HTML parsing
zod: Runtime type validation
winston: Logging
joi: Validation
uuid: ID generation
MIT
Contributions are welcome! Please feel free to submit issues or pull requests.
For issues or questions:
Check the Aceternity UI documentation: https://ui.aceternity.com
Review the MCP specification: https://modelcontextprotocol.io
Open an issue in this repository
Get detailed information about a specific Aceternity UI component by its slug
| Name | Required | Description | Default |
|---|---|---|---|
| componentName | Yes | The slug or name of the component (e.g., "background-beams", "animated-modal") |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It only says 'detailed information' without specifying what that includes, nor does it mention output format, errors, permissions, or side effects. The tool is likely a read operation, but this is not disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that is front-loaded with the action ('Get detailed information') and the target ('specific Aceternity UI component'). No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter tool, the description is adequate but vague about what 'detailed information' includes, especially since there is no output schema. The lack of guidance on alternatives and return structure leaves gaps, but the simplicity makes it minimally viable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema fully documents the single parameter with a description and example, achieving 100% coverage. The description itself adds minimal semantic value beyond restating 'by its slug'; the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool fetches detailed information about a specific component identified by slug. This distinguishes it from siblings like list_components (which likely returns all) and search_components (which likely finds matching components).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when you have a specific slug and need detailed data, providing clear context. However, it does not explicitly mention alternatives or when not to use this tool, such as 'use search_components to find a component first.'
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all available Aceternity UI components, optionally filtered by category
| Name | Required | Description | Default |
|---|---|---|---|
| category | No | Optional category filter (e.g., "backgrounds", "3d", "overlays", "carousel", "layout", "visualization") |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It only states the core function without revealing traits such as read-only behavior, return format, pagination, or error handling. The word 'List' implies safety but does not explicitly confirm it, leaving significant gaps for a tool with no annotation-driven visibility.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that directly states the purpose and optional filter. There is no wasted wording or redundant elaboration, making it highly concise and appropriately structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema and no annotations, so the description should explain return values or additional context, but it does not. It also omits details like whether the list is paginated, sorted, or includes metadata. Despite the tool's simplicity, the missing return/error information leaves it incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage for the single 'category' parameter is 100%, and the parameter description already explains it with examples. The tool description only restates that filtering is optional, adding no new semantics like matching behavior or invalid-category handling, so it meets the baseline but does not elevate it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists all available Aceternity UI components, with an optional category filter. The verb 'List' and resource 'Aceternity UI components' are specific, and it distinguishes from siblings like get_component (single item) and search_components (query-based) by indicating 'all' components.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for browsing all components or filtering by category, which provides a clear context. However, it does not explicitly mention when to avoid this tool in favor of siblings like get_component or search_components, so it misses explicit exclusions or alternative guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search for Aceternity UI components by name, description, or tags
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Search query (e.g., "animation", "gradient", "3d", "modal") |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states searchable fields and does not disclose return format (list vs. single), matching behavior (e.g., partial vs. exact), pagination, or result limits. This is a significant gap for a search tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one concise sentence, front-loaded with the action verb and resource. Every word earns its place, with no redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter search tool, the description provides adequate purpose, but it lacks return value details and does not explicitly differentiate from sibling tools. The absence of an output schema and behavioral context leaves the agent uncertain about what the search will produce, making it only minimally complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%: the single required parameter 'query' already has a description with examples. The tool description reinforces that search is by name/description/tags, but adds no new meaning beyond the schema. Baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Search'), identifies the resource ('Aceternity UI components'), and specifies search criteria ('by name, description, or tags'). This clearly distinguishes it from the sibling tools get_component (which likely retrieves a single component) and list_components (which likely lists all components).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies use when searching for components by name/description/tags, which gives clear context. However, it does not explicitly exclude alternatives (e.g., 'use get_component if you know the ID') or mention sibling tools, so it lacks explicit when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v1.1.0get_componentlist_componentssearch_componentsThe three tools have distinct purposes: list for browsing, search for querying, and get for retrieving a specific item. However, list with category filtering and search by text could occasionally overlap if users search by category name, but descriptions clarify the intended use.
All tool names follow the consistent verb_noun pattern: get_component, list_components, search_components. The pattern is uniform and predictable.
Three tools is minimal but appropriate for a read-only component browsing server. It covers the core operations without bloat, though one additional tool (e.g., get_categories) might round it out slightly.
For its purpose of browsing a UI component library, the set provides list, search, and detail retrieval—covering the essential workflows. A minor gap is the lack of an explicit category listing endpoint, but list_components with category filtering mitigates this.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
The documentation, as a tool your agent can call: 950+ AI-dev guides. Search + fetch tools.
Search 21st.dev UI components & themes, get their code, and generate new ones with 21st AI.
Versioned documentation registry and semantic search for AI tools and coding assistants.
Search Assetzaar's catalog of UI components, agent skills, SaaS kits and automations.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/yeshsurya/AceternityUI_MCP_Server'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
