A
licenseB
qualityB
maintenanceAn AI-powered tool that generates modern UI components from natural language descriptions, integrating with popular IDEs to streamline UI development workflow.
4
16,596
5,759
ISC
FlyonUI MCP Server
Enables community discussions and support through the Discord platform for FlyonUI users
Supports Tailwind design system integration with Figma for UI component design and prototyping
Facilitates discussions, bug reporting, and contribution to the FlyonUI ecosystem
Provides UI components and blocks optimized for Next.js framework development
Supports building UI components and blocks specifically for Nuxt framework projects
Offers specialized UI components and blocks for React-based application development
Enables creation of UI components and blocks tailored for Svelte framework projects
Provides tutorial videos for installation and usage of the FlyonUI MCP Server
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., "@FlyonUI MCP Server/cui Create a responsive navbar for my Next.js e-commerce site"
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.
FlyonUI MCP Server
Build modern, production-ready UI blocks, components, and landing pages in minutes. Seamlessly integrates with your favorite IDE and supports the most popular frameworks like React, Next.js, Nuxt, Vue, Svelte, and more.
🚀 What is FlyonUI MCP Server?
FlyonUI MCP Server is an Tailwind AI builder that helps you create, inspire, and refactor stunning, production-ready blocks, UI components and full pages using FlyonUI blocks. It easily integrates directly into your favorite IDE for a fast & efficient workflow.
Try FlyonUI MCP Server for free today.
Related MCP server: Magic Component Platform
🛠️ Installation
We’ve made installation super easy!
Access the Installation Guide and select your IDE (VS Code, Cursor, Windsurf, etc.).
Follow the step-by-step instructions to set up MCP Server in your IDE.
Start using FlyonUI MCP Server for free.
See the complete installation video FlyonUI MCP Installation.
📒 Documentation
FlyonUI MCP Server is designed to be intuitive and easy to use. The commands are simple and straightforward, allowing you to create, inspire, and refine UI blocks quickly.
For detailed documentation on how to use FlyonUI MCP Server, please refer to the FlyonUI MCP Documentation.
🔧 Usage
FlyonUI MCP Server provides three main commands:
Command | Description | Use Case |
| Create UI | Customize from existing FlyonUI blocks |
| Inspire UI | Generate new, creative UI blocks |
| Refine UI | Refine or edit an existing block |
See the complete Documentation for using FlyonUI MCP Server here: FlyonUI MCP Documentation.
Watch video tutorial here: FlyonUI MCP Usage.
Examples
Create UI (/cui):
/cui Create a hero section for an eLearning Academy site.
/cui Create a feature section for my landing page like Features 8.Inspire UI (/iui):
/iui Create a hero section for my AI SaaS - AI Video Generator.
/iui Create a feature section for my productivity app.Refine UI (/rui):
/rui Update the theme to Shadcn.
/rui Replace the “Get Started” button with Login and Register buttons.
/rui Change the Hero section layout from horizontal to vertical.📚 Documentation & Resources
Community 🤝
Join the FlyonUI community to discuss the library, ask questions, and share your experiences:
Contributing 📝
Fix a bug, or add a new feature. You can make a pull request and see your code in the next version of FlyonUI MCP.
Before adding a pull request, please see the contributing guidelines.
💬 Support
Available Tools
6 toolsget-block-contentGet Block DataC
Fetch the content of a block from a given URL. Use this tool to retrieve the code block content from the authenticated URL.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| endpoint | Yes | ||
| type | Yes |
TDQS
C2.7/5.0
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description only implies a read operation ('Fetch'). It mentions 'authenticated URL' but does not disclose other behavioral traits such as side effects, rate limits, or error conditions.
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 consists of two concise sentences that efficiently convey the core action and usage intent. Minor redundancy ('from a given URL' and 'from the authenticated URL') does not significantly detract.
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?
With no output schema, no annotations, and two undocumented parameters, the description fails to explain the output format, the meaning of 'type', or what constitutes a 'block'. Siblings exist but are not differentiated.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage for parameters. The description only hints that 'endpoint' is a URL but does not explain the 'type' parameter or provide format details beyond what the schema names show.
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 fetches block content from a URL and specifies 'code block content', which differentiates it from siblings like 'get-block-meta-content' that likely fetch metadata. However, it does not explicitly contrast with siblings.
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 says 'Use this tool to retrieve the code block content from the authenticated URL' but provides no guidance on when not to use it or how it compares to alternative sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get-block-meta-contentGet Block Meta ContentC
Fetch the content of the block metadata from the FlyonUI MCP server. Use this tool to retrieve the block metadata content.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| endpoint | Yes |
TDQS
C2.3/5.0
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, and the description only states 'Fetch', implying read-only, but does not disclose any behavioral traits such as side effects, required permissions, rate limits, or response structure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short (two sentences), but it lacks necessary information, making it under-specified rather than concise. Every sentence is vague.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, no output schema, and a single undocumented parameter, the description fails to provide adequate context for an agent to use the tool effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has a single required parameter 'endpoint' with no description, and the description provides zero information about its meaning, format, or valid values (0% schema description coverage).
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 uses verbs 'Fetch' and 'retrieve' with the resource 'block metadata content', but it doesn't clearly differentiate from sibling tools like 'get-block-content' or 'get-blocks-metadata', leaving ambiguity about what 'metadata content' specifically means.
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. The description lacks any context about prerequisites or exclusions, leaving the agent without decision criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get-blocks-metadataGet Block MetadataD
Fetch the metadata of a block from a given URL. Use this tool to retrieve the block metadata. This will provide the metadata of all the FlyonUI blocks available for use.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
TDQS
D1.9/5.0
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description should fully disclose behavior. It claims to fetch metadata but does not state whether it is read-only, if it requires a URL (contradicts schema), or what the output format is. The mention of 'all blocks' versus 'from a given URL' is unclear.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short but redundant: 'Fetch the metadata' and 'retrieve the block metadata' say the same thing. The inconsistency between URL and all blocks adds confusion, wasting the brevity.
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 parameters and no output schema, the description should at least clarify what metadata is returned (e.g., list of properties) and resolve the URL contradiction. It fails to provide a complete understanding of the tool's behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, but the description incorrectly implies a URL parameter ('from a given URL'), misleading the agent. Since there are no parameters, the description should confirm that no input is needed, but instead it suggests an undefined parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Fetch the metadata of a block from a given URL' but the input schema has no URL parameter, creating a contradiction. It also conflates retrieving a single block's metadata with 'all the FlyonUI blocks', causing ambiguity. No differentiation from sibling tools like get-block-content or get-block-meta-content.
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. The description only says 'Use this tool to retrieve block metadata' but does not explain why one would choose it over get-block-content or get-block-meta-content.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get-create-instructionsGet Instructions for FlyonUI.B
Get instructions for creating FlyonUI blocks using existing blocks. This tool provides instructions for creating new FlyonUI blocks using existing blocks. Use this tool when the user requests to generate a new component. mentions /create-flyonui or /cui. Strictly follow the steps one by one to ensure successful code generation.Retrieves Instructions for IDE agent to follow for creating/generating/updating FlyonUI blocks.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
TDQS
B3.2/5.0
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavior. It states the tool provides instructions but does not clarify if it is read-only, requires authentication, or has side effects. The instruction to 'strictly follow steps' hints at process, but deeper behavioral traits are missing.
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 repetitive ('Get instructions for...using existing blocks' is stated twice) and contains a run-on sentence at the end. It is not overly long but could be more concise.
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?
Despite having no parameters or output schema, the description fails to specify the format or content of the returned instructions. It is adequate for a simple instruction-retrieval tool but lacks detail on what the output contains.
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 input schema has zero parameters with 100% schema description coverage, so the description adds no parameter-level meaning. Per guidelines, 0 parameters warrants a baseline of 4.
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 that the tool retrieves instructions for creating/generating/updating FlyonUI blocks, and it specifies a trigger phrase ('mentions /create-flyonui or /cui'). However, it does not distinguish well from sibling tools like 'get-refine-instructions'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes explicit guidance on when to use ('when the user requests to generate a new component') and mentions specific triggers, but it lacks explicit exclusion criteria or comparisons to alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get-inspire-instructionsGet Instructions for generating FlyonUI blocks using the existing FlyonUI blocks as an inspiration.A
Get instructions for working with FlyonUI blocks. This tool provides instructions for creating new FlyonUI blocks by taking the inspiration from existing FlyonUI blocks. Use this tool when the user requests to generate a new component by inspirations. mentions /inspire-flyonui or /iui.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
TDQS
A4.1/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It describes the action (get instructions) but does not disclose any side effects, permissions, or format of output. Adequate but not rich.
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?
Two sentences, every word earns its place. Purpose and trigger conditions are front-loaded with no redundancy.
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?
For a simple tool with no output schema, the description gives purpose and usage but does not explain the format or content of the instructions returned. Adequate but could be more complete.
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 in schema, and description does not need to add parameter info. Baseline 4 for 0 parameters as per guidelines.
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 it provides instructions for creating new FlyonUI blocks by inspiration, with specific trigger phrases. It distinguishes from siblings like get-create-instructions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use ('when the user requests to generate a new component by inspirations' and trigger phrases), but does not explicitly exclude alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get-refine-instructionsGet Instructions for refining flyonui blocks/code/component or page.A
Get instructions for refining FlyonUI blocks. This tool provides instructions for refining existing FlyonUI blocks. Use this tool when the user requests to refine an existing component. mentions /refine-flyonui or /rui.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
TDQS
A4.3/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It states its function but doesn't disclose details like return format or constraints, though it's a simple query tool.
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?
Three sentences with front-loaded purpose, but second sentence is somewhat redundant. Overall concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with no parameters or output schema, description covers purpose, usage context, and trigger phrases. Could mention return type but not essential.
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 in schema, so description doesn't need to add param info. It appropriately lacks param details.
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?
Clearly states it provides instructions for refining FlyonUI blocks, and distinguishes from siblings like get-create-instructions by specifying 'refine an existing component'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says to use when user requests to refine an existing component, and gives trigger mentions /refine-flyonui or /rui, providing clear context and alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
6 tool updates
- First observed
get-block-content - First observed
get-block-meta-content - First observed
get-blocks-metadata - First observed
get-create-instructions - First observed
get-inspire-instructions - First observed
get-refine-instructions
TDQS
B3.1/5.0
Disambiguation4/5
Tools are largely distinct but 'get-block-meta-content' and 'get-blocks-metadata' could cause confusion as one fetches single block metadata content and the other all blocks metadata. Descriptions help disambiguate.
Naming Consistency5/5
All tools follow a consistent 'get-{target}' pattern with hyphens, making them predictable and easy to understand.
Tool Count5/5
With 6 tools, the server is well-scoped for its purpose of retrieving block content, metadata, and instructions without being bloated.
Completeness3/5
The tool set covers retrieval and workflow instructions but lacks actual create, update, or delete operations for blocks, leaving gaps in lifecycle coverage.
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
Build and manage your design system with AI: tokens, themes, components, icons, Figma and code.
Marketing autopilot in your IDE. AI turns codebase and context into content for 10+ platforms
AI-powered design and management for Webflow Sites
Build, deploy, and sell AI agents for local-service businesses - from your IDE.
Related MCP Servers
- FlicenseBqualityDmaintenanceAI-driven tool that helps developers create beautiful UI components instantly through natural language descriptions, integrating with popular IDEs like Cursor, Windsurf, and VSCode.32-
- AlicenseBqualityDmaintenanceEnables developers to generate beautiful, modern UI components through natural language descriptions. Integrates with popular IDEs to instantly create and customize React components inspired by 21st.dev's component library.418ISC
- AlicenseBqualityFmaintenanceProvides comprehensive tools for TailwindCSS development including utility class retrieval, CSS-to-Tailwind conversion, and color palette generation. It enables AI assistants to search documentation, generate component templates, and provide framework-specific installation guides.81,36839MIT
Appeared in Searches
- A tool for evaluating Tailwind CSS class quality in HTML
- Modern clean web UI frameworks for TypeScript websites
- MCP servers for full-stack development, DevOps, Supabase, QA, and AI agent orchestration
- React Native Android development with JavaScript and Tailwind UI
- Popular MCP tools for front-end development
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
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/themeselection/flyonui-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server