The Magic UI MCP Server provides a foundation for building interactive and dynamic applications with AI-integrated UI components using the Model Context Protocol (MCP). With this server, you can:
Access a comprehensive library of UI components through the getUIComponents endpoint
Implement various layouts (bento-grid, dock, file-tree) using getLayout
Work with media components like hero-video-dialog and terminal via getMedia
Add motion effects such as blur-fade and scroll-progress through getMotion
Enhance text with animations including typing-animation and morphing-text
Create interactive buttons (rainbow-button, shimmer-button) with getButtons
Apply visual effects like animated-beam and magic-card using getEffects
Build widgets such as animated-list and tweet-card
Design dynamic backgrounds including warp-background and flickering-grid
Emulate devices like Safari, iPhone 15 Pro, and Android
Offers community engagement through Discord, allowing users to join and participate in discussions about Magic UI MCP server development and usage.
Enables access to repository functions for downloading releases, contributing via pull requests, and participating in issue discussions for the Magic UI MCP server.
Allows creating Magic UI components using JavaScript, enabling interactive and dynamic application development with the MCP server.
Incorporates Magic UI components and design principles, providing a foundation for building Magic UI-enhanced applications with AI capabilities.
Provides integration with npm for starting the server and managing Magic UI components for application development.
Integrates with Shields.io for displaying badges in the documentation, representing server version and community information.
Click on "Deploy 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., "@Magic UI MCP Server create a responsive login form with validation"
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.
Welcome to the official Magic UI MCP server repository. This project serves as a foundation for building interactive and dynamic applications using the Model Context Protocol (MCP). Our aim is to create a seamless integration of AI and UI design principles, making it easier for developers to harness the power of Magic UI.
Related MCP server: MCP Server Demo
AI Integration: Utilize advanced AI capabilities to enhance user experience.
Magic UI Components: Access a rich library of UI components tailored for modern applications.
Customizable Protocols: Adapt the Model Context Protocol to fit your specific needs.
Community Driven: Join a vibrant community of developers and designers.
To get started, download the latest release from our Releases section. Once downloaded, follow these steps:
Unzip the File: Extract the downloaded file.
Run the Setup: Execute the installation script found in the unzipped folder.
Configure the Server: Follow the on-screen instructions to set up your server environment.
Once installed, you can start using the MCP server by running the following command in your terminal:
npm startThis will launch the server, allowing you to access the Magic UI components and AI functionalities.
Here’s a simple example of how to create a Magic UI component:
import { MagicButton } from 'magic-ui';
const MyComponent = () => {
return (
<MagicButton onClick={() => alert('Hello, Magic UI!')}>
Click Me
</MagicButton>
);
};We welcome contributions from the community. To contribute:
Fork the Repository: Create your own copy of the repository.
Make Changes: Implement your features or fixes.
Submit a Pull Request: Share your changes with us for review.
For detailed guidelines, check our CONTRIBUTING.md.
This project is licensed under the MIT License. See the LICENSE file for details.
For any questions or feedback, please reach out to us via GitHub issues or email us at support@magicui.com.
For the latest updates and releases, visit our Releases section. Make sure to download the latest version to enjoy new features and improvements.
This repository focuses on several key topics:
AI: Explore how artificial intelligence can enhance user interactions.
Magic UI: Discover the design principles behind Magic UI components.
Magic UI Design: Learn best practices for designing with Magic UI.
MCP: Understand the Model Context Protocol and its applications.
Model Context Protocol: Dive deep into the protocol's functionalities and benefits.
We would like to thank the community for their continuous support and contributions. Your feedback helps us improve and evolve the MCP server.
Become a part of our growing community. Share your projects, ideas, and experiences with us. Together, we can build amazing applications using the Magic UI MCP server!
Thank you for checking out the MCP server! We look forward to seeing what you create.
Provides implementation details for warp-background, flickering-grid, animated-grid-pattern, retro-grid, ripple components.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
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 states what the tool does ('provides implementation details') but lacks critical behavioral traits: it doesn't specify the format of the details (e.g., code snippets, documentation, examples), whether it's a read-only operation, potential errors, or any performance considerations. For a tool with zero annotation coverage, this is a significant gap in transparency.
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, efficient sentence that directly states the tool's function and lists the specific components it covers. It's front-loaded with the core purpose and avoids any unnecessary words or structure, making it highly concise and well-structured for quick understanding.
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?
Given the tool's complexity (simple retrieval with no parameters) and the absence of annotations and output schema, the description is minimally adequate. It identifies the components but doesn't explain the nature of the 'implementation details' (e.g., what format they're in, how they're returned). For a tool with no structured output information, more detail on the return value would enhance completeness, but it meets a basic threshold.
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 tool has 0 parameters, and the schema description coverage is 100%, so there's no need for parameter details in the description. The description appropriately focuses on the tool's purpose without redundant parameter information. A baseline of 4 is applied since no parameters exist, and the description doesn't attempt to explain non-existent inputs.
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: 'Provides implementation details for warp-background, flickering-grid, animated-grid-pattern, retro-grid, ripple components.' It specifies the verb ('provides') and the resources (five named components), making the function unambiguous. However, it doesn't explicitly differentiate from sibling tools like 'getEffects' or 'getUIComponents', which might also provide implementation details for related components, preventing a perfect score.
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 offers no guidance on when to use this tool versus alternatives. It lists the components it covers but doesn't explain why one would choose this over sibling tools such as 'getEffects' or 'getUIComponents', which might handle similar or overlapping functionality. There's no mention of prerequisites, context, or exclusions, leaving usage unclear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Provides implementation details for rainbow-button, shimmer-button, shiny-button, interactive-hover-button, animated-subscribe-button, pulsating-button, ripple-button components.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It states what the tool provides (implementation details) but doesn't describe how it behaves: format of returned details, whether it's a read-only operation, potential errors, or any performance characteristics. For a tool with zero annotation coverage, this leaves significant behavioral gaps.
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, efficient sentence that lists all covered components. It's appropriately sized for a tool that returns implementation details. While it could be more structured (e.g., separating component types), it wastes no words and gets straight to the point.
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?
Given the tool's complexity (parameterless read operation) and lack of annotations/output schema, the description is minimally adequate. It tells what the tool provides but doesn't explain the format, scope, or limitations of the implementation details. For a tool with no structured output documentation, more detail about return values would be helpful.
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 tool has 0 parameters with 100% schema description coverage, so the schema already fully documents the parameter situation. The description appropriately doesn't discuss parameters since none exist. It focuses on what the tool returns rather than what it accepts, which is correct for a parameterless tool.
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: providing implementation details for specific button components. It lists the exact components covered (rainbow-button, shimmer-button, etc.), making the verb+resource relationship explicit. However, it doesn't differentiate this tool from its siblings (like getUIComponents or getWidgets) which might also provide component details.
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 provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites, when this tool is appropriate versus other sibling tools like getUIComponents or getWidgets, or any contextual constraints. The user must infer usage from the component list alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Provides implementation details for safari, iphone-15-pro, android components.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions 'implementation details' but doesn't specify what format these details come in, whether they're read-only, if there are rate limits, or any behavioral traits. The description is too vague to provide meaningful behavioral context.
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 sentence that's reasonably concise, but it's not particularly well-structured or front-loaded with the most critical information. It could be more efficiently worded to clarify the tool's specific value.
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?
Given no annotations, no output schema, and a tool that presumably returns implementation details, the description is incomplete. It doesn't explain what kind of details are returned, in what format, or for what purpose. The description leaves too many questions unanswered for effective tool selection.
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 tool has 0 parameters with 100% schema description coverage, so the schema already fully documents the lack of parameters. The description doesn't need to compensate for any parameter gaps, and it appropriately doesn't mention parameters since none exist.
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 states 'Provides implementation details for safari, iphone-15-pro, android components' which gives a general purpose but is vague about what specific details are provided and what 'components' refers to. It doesn't clearly distinguish this tool from its siblings like getUIComponents or getWidgets that might also provide component-related information.
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 its siblings. The description doesn't mention alternatives, prerequisites, or specific contexts where this tool is appropriate versus other component-related tools in the server.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Provides implementation details for animated-beam, border-beam, shine-border, magic-card, meteors, neon-gradient-card, confetti, particles, cool-mode, scratch-to-reveal components.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
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 states the tool 'Provides implementation details,' implying a read-only, informational function, but doesn't specify what those details include (e.g., code snippets, documentation, examples), how they're formatted, or any limitations like rate limits or authentication needs. This leaves significant gaps in understanding the tool's behavior.
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, efficient sentence that lists all 10 components without unnecessary words. It's front-loaded with the core purpose ('Provides implementation details'), and every part of the sentence directly contributes to specifying the tool's scope. There's zero waste or 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?
Given the tool's complexity (informational with no parameters) and the absence of annotations and output schema, the description is minimally complete. It identifies the target components but lacks details on what 'implementation details' entail, such as response format or content depth. For a tool with no structured data support, this leaves the agent with incomplete context for effective use.
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 input schema has 0 parameters with 100% coverage, meaning no parameters are documented or required. The description doesn't add parameter information, which is appropriate here. Since there are no parameters, the baseline score is 4, as the description needn't compensate for any schema gaps.
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: to 'Provides implementation details for' a specific list of 10 UI components. It uses a specific verb ('Provides') and identifies the resource (the listed components), making the purpose unambiguous. However, it doesn't explicitly differentiate from sibling tools like 'getTextEffects' or 'getTextReveal', which might have overlapping domains.
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 provides no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools like 'getTextEffects' or 'getUIComponents', nor does it specify contexts or prerequisites for usage. The agent must infer usage from the component list alone, which offers minimal direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Provides implementation details for bento-grid, dock, file-tree, grid-pattern, interactive-grid-pattern, dot-pattern components.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool 'provides implementation details,' which implies a read-only operation, but doesn't clarify if it's safe, requires authentication, has rate limits, or what format the details are in. The description is too vague about the tool's behavior beyond its basic purpose.
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, efficient sentence that directly states the tool's purpose and scope. It's front-loaded with the key action ('Provides implementation details') and lists the components without redundancy. However, it could be slightly more structured by grouping components or adding brief context, but it's still very concise.
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?
Given the tool has no annotations, no output schema, and 0 parameters, the description is incomplete. It doesn't explain what 'implementation details' entail (e.g., code snippets, configurations, usage examples), the format of the output, or any behavioral aspects like error handling. For a tool with such sparse structured data, the description should provide more context to be fully helpful.
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 input schema has 0 parameters with 100% coverage, so there are no parameters to document. The description doesn't need to add parameter semantics, and it appropriately doesn't mention any. This meets the baseline for tools with no parameters, as it avoids unnecessary information.
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 what the tool does ('Provides implementation details') and specifies the exact components it covers (bento-grid, dock, file-tree, etc.). It distinguishes itself from siblings by focusing on layout components rather than backgrounds, buttons, devices, etc. However, it doesn't explicitly contrast with similar tools (none exist in siblings), so it's not a perfect 5.
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 provides no guidance on when to use this tool versus alternatives. It lists the components it covers but doesn't explain why one would choose this over other tools like getUIComponents or getWidgets, nor does it mention any prerequisites or contextual triggers for usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Provides implementation details for hero-video-dialog, terminal, marquee, script-copy-btn, code-comparison components.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden but lacks behavioral details. It doesn't disclose if this is a read-only operation, what format the details are in (e.g., code, documentation), or any constraints like rate limits or authentication needs. The description is minimal and fails to compensate for the absence of annotations.
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 sentence that lists component types, which is concise but lacks structure. It front-loads the purpose ('Provides implementation details') but could be more efficient by clarifying the action or resource, and the list of components feels somewhat arbitrary without grouping or prioritization.
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?
Given the complexity (retrieving details for multiple components), no annotations, and no output schema, the description is incomplete. It doesn't explain what 'implementation details' entail (e.g., code snippets, configurations, usage examples) or the return format, leaving significant gaps for the agent to infer behavior.
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 input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description doesn't add parameter semantics, but this is acceptable given the lack of parameters, aligning with the baseline of 4 for zero parameters as per the rules.
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 states what the tool provides ('implementation details') but is vague about the specific action and resource. It lists component types (hero-video-dialog, terminal, etc.) without clarifying if this retrieves, lists, or analyzes them, and doesn't distinguish from siblings like 'getUIComponents' or 'getWidgets' that might overlap in scope.
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 is provided. The description lists component types but doesn't specify contexts (e.g., for development, debugging, or UI assembly) or exclusions, leaving the agent to guess based on sibling tool names like 'getUIComponents' without explicit differentiation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Provides implementation details for blur-fade, scroll-progress, scroll-based-velocity, orbiting-circles, animated-circular-progress-bar components.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
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 what the tool provides (implementation details) without describing how it behaves—e.g., whether it returns code snippets, documentation, examples, or if it's read-only, has rate limits, or requires authentication. This leaves significant gaps in understanding the tool's operation.
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, efficient sentence that directly states the tool's function without unnecessary words. It's front-loaded with the key action ('Provides implementation details') and lists specific components. However, it could be slightly more structured by grouping components or clarifying the output format.
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?
Given the complexity (providing details for multiple UI components) and lack of annotations and output schema, the description is incomplete. It doesn't explain what 'implementation details' entail (e.g., code, docs, examples), the format of the return value, or any behavioral aspects like error handling. This leaves too much ambiguity for effective use.
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 input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description appropriately doesn't discuss parameters, focusing instead on the tool's purpose. This meets the baseline for tools without parameters, as there's nothing to compensate for.
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: providing implementation details for specific UI components (blur-fade, scroll-progress, etc.). It uses a specific verb ('Provides') and identifies the resource (implementation details for named components). However, it doesn't explicitly distinguish this tool from its siblings like 'getUIComponents' or 'getEffects', which might have overlapping functionality.
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 offers no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites, exclusions, or compare it to sibling tools like 'getUIComponents' or 'getEffects', which might cover similar or related components. Users must infer usage from the component list alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Provides implementation details for word-rotate, flip-text, hyper-text, morphing-text, spinning-text, sparkles-text components.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
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. While 'Provides implementation details' suggests a read-only operation, it doesn't explicitly state whether this requires authentication, has rate limits, returns structured data, or involves any side effects. For a tool with zero annotation coverage, this leaves significant behavioral gaps.
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, efficient sentence that directly states the tool's purpose and lists the specific components covered. Every word earns its place with no redundancy or unnecessary elaboration. It's appropriately sized and front-loaded with the core functionality.
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?
Given the tool has no parameters and no output schema, the description adequately covers what the tool does (provides implementation details for specific text effects). However, without annotations or output schema, it lacks information about return format, authentication needs, or error handling. The description is complete enough for basic understanding but has gaps in behavioral context.
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 input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description appropriately doesn't discuss parameters, maintaining focus on the tool's purpose. This meets the baseline for tools with no parameters.
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: providing implementation details for specific text effect components (word-rotate, flip-text, hyper-text, morphing-text, spinning-text, sparkles-text). It uses the verb 'Provides' with the resource 'implementation details' and lists the specific components covered. However, it doesn't explicitly differentiate from sibling tools like 'getEffects' or 'getTextReveal' which might have overlapping functionality.
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 provides no guidance on when to use this tool versus alternatives. It doesn't mention any prerequisites, context for usage, or comparison with sibling tools like 'getEffects' (which might be more general) or 'getTextReveal' (which might be more specific). The agent must infer usage from the component list alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Provides implementation details for text-animate, line-shadow-text, aurora-text, animated-shiny-text, animated-gradient-text, text-reveal, typing-animation, box-reveal, number-ticker components.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It only states what the tool provides (implementation details) but doesn't describe how it behaves—e.g., whether it returns code snippets, documentation, examples, or if it requires authentication, has rate limits, or affects system state. This leaves significant gaps for an agent to understand operational 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 a single, efficient sentence that lists all covered components without unnecessary words. It's front-loaded with the core purpose ('Provides implementation details') and uses a bullet-like list format for the components, making it highly concise and well-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?
Given the tool has 0 parameters and no output schema, the description is minimally adequate by stating what it provides. However, it lacks context on the format of the implementation details (e.g., code, docs, examples) and doesn't address behavioral aspects like safety or performance, which are important for a tool with no annotations. This makes it incomplete for full agent understanding.
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 input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description appropriately doesn't discuss parameters, earning a high baseline score. However, it doesn't explicitly state 'no parameters required,' which could slightly improve clarity, preventing a perfect 5.
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 'provides implementation details' for specific text animation components, which is a specific verb+resource combination. However, it doesn't differentiate from sibling tools like 'getTextEffects' or 'getUIComponents' that might overlap with text-related functionality, preventing a perfect score.
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 provides no guidance on when to use this tool versus alternatives like 'getTextEffects' or 'getUIComponents' from the sibling list. It simply lists what it covers without context about appropriate 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.
Provides a comprehensive list of all Magic UI components.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
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. While 'Provides a comprehensive list' suggests a read-only operation that returns data, it doesn't specify format (e.g., JSON array), pagination behavior, rate limits, authentication requirements, or error conditions. For a tool with zero annotation coverage, this leaves significant behavioral gaps.
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, efficient sentence that directly states the tool's function without unnecessary words. It's appropriately sized for a simple tool and front-loaded with the core purpose. Every word earns its place.
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?
Given the tool's simplicity (0 parameters, no output schema, no annotations), the description is minimally adequate. It states what the tool does but lacks details about return format, behavioral constraints, or differentiation from siblings. For a read operation with no structured output documentation, more context about what 'comprehensive list' means would be helpful.
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 tool has 0 parameters, and schema description coverage is 100% (empty schema is fully described). With no parameters to document, the description doesn't need to add parameter semantics beyond what the schema provides. The baseline for 0 parameters is 4, as there's nothing to compensate for.
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: 'Provides a comprehensive list of all Magic UI components.' It uses a specific verb ('Provides') and identifies the resource ('Magic UI components'). However, it doesn't explicitly differentiate from sibling tools like getButtons or getWidgets, which appear to be more specific subsets of UI 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 provides no guidance on when to use this tool versus alternatives. With multiple sibling tools like getButtons and getWidgets that seem related to UI components, there's no indication of whether this tool is comprehensive (listing all components) while others are filtered subsets, or how they differ in scope or functionality.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Provides implementation details for animated-list, tweet-card, client-tweet-card, lens, pointer, avatar-circles, icon-cloud, globe components.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions 'implementation details' but doesn't disclose behavioral traits like whether this is a read-only operation, if it requires authentication, rate limits, or what format the details are returned in. This leaves significant gaps for a tool with no annotation coverage.
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 sentence that lists components efficiently, with no wasted words. It's appropriately sized for a tool with no parameters, though it could be more front-loaded by clarifying the purpose upfront.
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?
Given no annotations, no output schema, and a tool that presumably returns data (implementation details), the description is incomplete. It doesn't explain what 'implementation details' entails (e.g., code snippets, configurations, usage examples) or the return format, leaving the agent uncertain about the tool's behavior and output.
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 input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description doesn't add parameter semantics, but that's acceptable here. Baseline is 4 for 0 parameters, as the schema fully covers the absence of inputs.
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 states what the tool does ('Provides implementation details') and lists specific components, which gives a general purpose. However, it's vague about what 'implementation details' means (code, documentation, examples?) and doesn't clearly distinguish from siblings like 'getUIComponents' or 'getLayout' that might overlap with component-related functionality.
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. The description lists components but doesn't specify contexts, prerequisites, or exclusions. With siblings like 'getUIComponents' and 'getLayout', the agent has no help in choosing between them.
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.
v1.0.0getBackgroundsgetButtonsgetDevicesgetEffectsgetLayoutgetMediagetMotiongetTextEffectsgetTextRevealgetUIComponentsgetWidgetsScored across 11 tools
Every tool has a clearly distinct purpose focused on different categories of UI components (backgrounds, buttons, devices, effects, layout, media, motion, text effects, text reveal, UI components, widgets). There is no overlap in functionality—each tool retrieves implementation details for a specific, non-overlapping set of components.
All tool names follow a consistent 'get' + plural noun pattern (e.g., getBackgrounds, getButtons, getDevices). This uniform verb_noun structure makes the tool set predictable and easy to understand, with no deviations in naming conventions.
With 11 tools, the server is well-scoped for its purpose of providing UI component implementations. Each tool covers a distinct category, and the count is appropriate for comprehensive coverage without being overwhelming or too sparse.
The tool surface is complete for the domain of Magic UI components, covering a wide range of categories from backgrounds to widgets. There are no obvious gaps—tools like getUIComponents provide a comprehensive overview, and other tools handle specific subcategories, ensuring agents can access all necessary implementation details without dead ends.
A comprehensive Model Context Protocol (MCP) server that enables AI assistants to interact with yo…
A Model Context Protocol server for Wix AI tools
Build personal interactive apps with real URLs and persistent storage, using any AI.
Automate 1,000+ services from any MCP-compatible AI agent: build Applets, run actions and queries.
