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 search for grid layout 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 seamless integration with the Aceternity UI component registry. This package enables AI assistants and applications to search, discover, and install Aceternity UI components programmatically.
Search Aceternity UI components by name, description, or tags
Get detailed information about any component
Get installation commands and setup instructions
List all available component categories
List all available components
Grouped category system for easy discovery
TypeScript implementation with Zod validation
Full Model Context Protocol (MCP) compliance for AI assistants and applications
Related MCP server: aceternity-mcp
Add to your Claude Desktop configuration file (~/Library/Application Support/Claude/claude_desktop_config.json on macOS):
{
"mcpServers": {
"aceternityui": {
"command": "npx",
"args": ["aceternityui-mcp"]
}
}
}Add the configuration to your Cursor settings:
{
"mcpServers": {
"aceternityui": {
"command": "npx aceternityui-mcp"
}
}
}Add the configuration to your Windsurf settings:
{
"mcpServers": {
"aceternityui": {
"command": "npx",
"args": ["aceternityui-mcp"]
}
}
}Add the following to your Warp session setup:
{
"aceternityui": {
"command": "npx",
"args": ["aceternityui-mcp"],
"working_directory": null,
"start_on_launch": true
}
}Use the standard MCP server connection with:
Command: npx aceternityui-mcp or node path/to/aceternityui-mcp/dist/index.js
Transport: stdio
No API key or special configuration is required.
search_components - Search for Aceternity UI components by name, description, or tags
get_component_info - Get detailed information about a specific component
get_installation_info - Get installation commands and setup for a component
list_categories - List all available component categories
get_all_components - Get a list of all available components
const results = await mcp.callTool("search_components", { query: "grid" });const info = await mcp.callTool("get_component_info", { componentName: "bento-grid" });const install = await mcp.callTool("get_installation_info", { componentName: "bento-grid" });const categories = await mcp.callTool("list_categories", {});const all = await mcp.callTool("get_all_components", {});Node.js 18+
npm or yarn
Clone the repository:
git clone https://github.com/rudra016/aceternityui-mcp.git
cd aceternityui-mcpInstall dependencies:
npm installBuild the project:
npm run buildRun in development mode:
npm run devFork the repository
Create your feature branch (git checkout -b feature/amazing-feature)
Commit your changes (git commit -m 'Add some amazing feature')
Push to the branch (git push origin feature/amazing-feature)
Open a Pull Request
This project is licensed under the MIT License - see the LICENSE file for details.
Create an issue for bug reports or feature requests
Check existing issues before creating new ones
Provide detailed information including error messages and environment details
Made with ❤️ for the developer community
Get a list of all available Aceternity UI components
| Name | Required | Description | Default |
|---|---|---|---|
| includeProOnly | No | Include pro-only components (default: false) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description confirms read-only behavior but doesn't mention pagination, sorting, or limits. Basic transparency but could be richer.
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?
Single sentence is concise and front-loaded. Could include brief parameter mention but not necessary for clarity.
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?
No output schema; description does not specify return format or content of the list (e.g., component objects, IDs, names). Lacks error and permission details.
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 is 100% for the single parameter, so baseline is 3. Description does not add any additional meaning beyond what the schema provides.
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?
Description clearly states the verb 'Get', resource 'list of all available Aceternity UI components', and distinguishes from siblings like search_components and get_component_info by implying a complete listing.
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?
No guidance on when to use this tool versus alternatives like search_components for filtering or get_component_info for details.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get detailed information about a specific Aceternity UI component
| Name | Required | Description | Default |
|---|---|---|---|
| componentName | Yes | Name of the component to get info for |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and the description only implies read-only behavior. It lacks disclosure of authentication needs, caching, or other behavioral traits, but is minimally adequate for a simple read 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?
Single sentence, no extraneous information, efficient and front-loaded.
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 tool with one parameter and no output schema, the description is complete. Could mention specifics of returned info, but not necessary.
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 is 100%, so the description adds no new meaning beyond the parameter name and type. Baseline score of 3 is appropriate.
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?
Clearly states the action ('get detailed information') and the resource ('a specific Aceternity UI component'), effectively distinguishing from siblings like 'get_all_components' and 'search_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?
No explicit guidance on when to use this tool versus alternatives, but the purpose is clear enough to infer use for detailed info on a known component.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get installation commands and setup instructions for a component
| Name | Required | Description | Default |
|---|---|---|---|
| componentName | Yes | Name of the component to get installation info for |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries full burden. It implies a read-only operation (getting info) but does not explicitly state safety, side effects, or error behavior. Adequate for a simple info retrieval 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?
Single sentence that directly conveys the tool's purpose. 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?
Tool is simple with one parameter and no output schema. Description sufficiently conveys functionality, though it could mention that it returns commands. Contextually complete for the complexity level.
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% (componentName described). The description adds no extra meaning beyond the schema; baseline 3 is appropriate.
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?
Description clearly states that the tool retrieves installation commands and setup instructions for a component. The verb 'Get' and resource 'installation commands and setup instructions' are specific and distinguish it from siblings like get_component_info or get_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?
No guidance on when to use this tool versus alternatives like get_component_info or search_components. The description does not provide usage context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all available component categories
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations; 'list all' implies read-only but no explicit behavioral traits beyond the obvious.
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?
Single short sentence, 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?
Tool is simple with no params; description fully covers its purpose and scope.
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?
No parameters; baseline 4 as description need not add param info.
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?
Clear verb 'list' and resource 'component categories'. Distinct from sibling tools which focus on components and installations.
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?
Implies usage when needing categories, but no explicit when-not or comparison to alternatives like search_components.
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 for components | |
| category | No | Filter by category (optional) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears full responsibility for behavioral disclosure. It does not mention any side effects, authentication requirements, rate limits, or constraints like pagination. The description only states the search capability without behavioral traits.
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 extremely concise (one sentence) and front-loaded with the core purpose. Every word contributes meaning without redundancy.
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 description is adequate for a simple search tool but lacks details on return format, result limits, or pagination. Given no output schema and no annotations, more context would be beneficial.
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?
Although schema coverage is 100%, the description adds meaning beyond the schema by explaining that the query parameter matches against name, description, or tags. This clarifies the semantic scope of the query parameter.
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's purpose: searching for Aceternity UI components. It includes the searchable fields (name, description, or tags), making it distinct from siblings like get_all_components (list all) and get_component_info (single item).
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?
No guidance is provided on when to use this tool versus alternatives or recommendations for query formatting. The description does not mention exclusions or contexts where other tools might be preferred.
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.0.1get_all_componentsget_component_infoget_installation_infolist_categoriessearch_componentsEach tool serves a distinct purpose: listing all components, getting details, installation info, categories, and searching. No overlap in functionality.
All tool names follow a consistent verb_noun pattern with snake_case, e.g., get_all_components, list_categories, search_components.
5 tools is well-scoped for a component library explorer, covering listing, search, details, categories, and installation without excess.
Core functionality is covered, but a tool to list components within a category is missing; however, search and get_all_components can compensate.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Driflyte MCP server which lets AI assistants query topic-specific knowledge from web and GitHub.
An MCP server that integrates with Discord to provide AI-powered features.
Search and install 4,000+ security-scanned MCP servers from inside any MCP-aware AI client.
An MCP server that gives your AI access to the source code and docs of all public github repos
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/rudra016/aceternityui-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
