How do I use ui-layouts-mcp?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@ui-layouts-mcp search for accordion 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.

ui-layouts-mcp

by ui-layouts

Overview Schema Related Servers Score Discussions

TypeScript

@ui-layouts/mcp

npm version node version

MCP Badge

@ui-layouts/mcp provides AI assistants with several valuable tools to help them search, understand, and retrieve UI components from ui-layouts.com.

Each tool can be used independently, but they are designed to work together as a complete "component exploration pipeline."

📦 Installation & MCP Setup

Requirements

Node.js: >=20.10.0
MCP Client: Claude Desktop, Cursor, or compatible MCP client

Quick Start

Run @ui-layouts/mcp without installing it globally using npx. This is the recommended way to get started:

{
  "mcpServers": {
    "ui-layouts-mcp": {
      "type": "stdio",
      "command": "npx",
      "args": ["@ui-layouts/mcp"]
    }
  }
}

💡 Note: npx will automatically download and run the latest version of @ui-layouts/mcp when needed. No global installation required!

Using with Claude Code (CLI)

claude mcp add ui-layouts-mcp --scope user -- npx -y @ui-layouts/mcp

This registers the MCP server under the CLI-safe name ui-layouts-mcp while still using the @ui-layouts/mcp npm package.

Related MCP server: MCP Vue UI Kit Server

🛠️ Tools

🔍 `search_components`

Search through the ui-layouts.com component registry by component name, key, group, tags, or href. It performs intelligent matching to find components that meet your criteria and returns detailed information about each match.

When it's useful

To find a specific UI component by name or tag
To explore available components by category
To discover components with particular design or functional features

📘 `get_docs`

Fetch the complete documentation for a component from ui-layouts.com. You can choose how much content to return, including:

raw_html — the original HTML of the documentation page
text — plain text extracted from HTML
snippet — the main section (e.g. <article> or <main> content only)

When it's useful

To read implementation guides and examples
To view a component’s structure, props, or variants
To extract technical explanations for AI-assisted reasoning or integration

🧩 `get_component_meta`

Fetch structured HTML metadata for a specific component from ui-layouts.com. It includes fields such as title, description, keywords, Open Graph, Twitter card, and even custom metadata like component-names and available-components.

When it's useful

To understand a component’s intent or SEO context
To generate previews or summaries automatically
To retrieve linked componentNames for source code lookup

💾 `get_source_code`

Fetch the actual TypeScript/React source code of a component directly from https://ui-layouts.com/r/{component}.json. The tool reads the files[].content field from the JSON registry and returns the .tsx implementation.

When it's useful

To review or analyze the source code of a component
To use the component implementation as a code example
To verify that a component matches your design or API expectations

💬 Prompts

The MCP server also provides reusable prompt templates that guide AI assistants to perform complex tasks using the available tools.

🎯 `find_component`

Help find the best ui-layouts component(s) for specific requirements, use cases, or design needs.

Parameters:

requirements: What you need (e.g. 'collapsible content sections with smooth animation')
tags (optional): Comma-separated tags to filter by (e.g. 'interactive,layout')
maxCandidates (optional): Max candidates to fetch docs for (default: '3', range: 1-10)

What it does:

Generates multiple search queries with synonyms
Calls search_components multiple times and merges results
Fetches documentation for top candidates using get_docs
Provides structured recommendations with:
- Recommended: name/key/href/tags, why, trade-offs
- Alternatives: 1-3 alternative options
- Next steps: Exact tool calls to continue

Strategy:

Uses intelligent search with synonyms (e.g. accordion/collapse/disclosure)
Prioritizes components matching provided tags
Ranks by relevance and compares multiple candidates

🛠️ `implement_component`

Get a step-by-step implementation guide for a ui-layouts component, including code examples, integration steps, and best practices.

Parameters:

componentKey (optional): Component key (e.g. 'accordion', 'sparkles-title')
componentHref (optional): Component href (e.g. '/components/accordion')
framework (optional): Target framework (e.g. 'react', 'next', 'vite', 'general', default: 'react')
includeSourceCode (optional): Whether to include source code ('true' or 'false', default: 'true')

What it does:

Fetches component documentation, metadata, and optionally source code
Generates a comprehensive implementation guide with:
- Overview: Component purpose, features, and when to use
- Installation: Dependencies and setup for the target framework
- Basic Usage: Minimal working example with explanations
- Configuration: Available props and customization options
- Advanced Examples: Real-world use cases with code
- Integration: Framework-specific setup and patterns
- Styling & Customization: Theming and appearance customization
- Best Practices: Performance tips, accessibility, common pitfalls
- Troubleshooting: Common issues and solutions

Output:

Practical, copy-paste ready code examples
Framework-specific integration guidance
Real code from source when available

🔗 Recommended Workflow

💡 Tip: Combine these tools for a full exploration experience: search_components → get_docs → get_component_meta → get_source_code

Step	Description	Example
①	Find components matching a keyword or tag	`search_components { "q": "accordion" }`
②	Fetch their documentation (HTML/Text)	`get_docs { "key": "accordion", "format": "snippet" }`
③	Retrieve metadata & component links	`get_component_meta { "key": "accordion" }`
④	Get TSX source code from registry	`get_source_code { "componentName": "single-layout-accordion" }`

⚙️ Server Info

MCP server name (alias): ui-layouts-mcp
npm package: @ui-layouts/mcp
Version: 0.3.0
Transport: stdio
Base URL: https://ui-layouts.com

🧠 Example Usage in Cursor / Claude

> call tool search_components { "q": "slider" }
> call tool get_docs { "key": "align-slider" }
> call tool get_component_meta { "key": "align-slider" }
> call tool get_source_code { "componentName": "align-slider" }

👤 Author (Naymur & Jinho)

Available Tools

4 tools

get_component_metaC

Fetch remote HTML metadata from https://ui-layouts.com by calling https://ui-layouts.com//<registry.href>.

ParametersJSON Schema

Name	Required	Description
`key`	No	DocsCategoryKey (e.g. 'sparkles-title')
`href`	No	DocsNavigationCategory href (e.g. '/components/sparkles-title')
`timeoutMs`	No
`pathPrefix`	No

TDQS

C2.6/5.0

Behavior2/5

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

No annotations are present, so the description carries the full burden. It implies a read-only network operation but does not disclose failure modes, authentication requirements, rate limits, or what 'metadata' includes. The URL template is also ambiguous.

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 brief (one sentence) and gets to the point, but it is not well-structured; the URL template is confusing and could have been clearer with parameter references or formatting.

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 there is no output schema and four parameters, the description is inadequate to confidently invoke the tool. It does not explain how to construct the URL correctly, what the returned HTML metadata contains, or error handling, leaving significant gaps.

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?

Schema covers only 50% of parameters (key and href have descriptions; timeoutMs and pathPrefix have defaults but no descriptions). The description adds the URL structure referencing pathPrefix and 'registry.href', but maps poorly to the actual 'href' parameter and fails to explain key and timeout semantics.

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?

Description states a clear action ('Fetch remote HTML metadata') and a specific resource (the URL on ui-layouts.com). It distinguishes from siblings (search, docs, source code) by focusing on raw metadata, though the URL template uses 'registry.href' which isn't a direct parameter name.

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

Usage Guidelines2/5

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

The description provides a URL pattern to invoke but does not specify when to choose this tool over the sibling tools (search_components, get_docs, get_source_code). No exclusions or alternative comparisons are given.

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

get_docsA

Fetch docs HTML for a component from ui-layouts.com and return as raw_html, plain text, or a main-section snippet.

ParametersJSON Schema

Name	Required	Description	Default
`key`	No	DocsCategoryKey (e.g. 'accordion')
`href`	No	DocsNavigationCategory href (e.g. '/components/accordion')
`format`	No		text
`maxChars`	No
`timeoutMs`	No
`pathPrefix`	No

TDQS

A3.6/5.0

Behavior3/5

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

With no annotations provided, the description must carry the behavioral disclosure burden. It reveals that the tool performs a network fetch and can return three different representations, but it does not explain error handling, rate limits, or side effects. It still conveys a read-only nature and output flexibility, which is partial transparency.

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

Conciseness4/5

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

The description is a single sentence with no filler, front-loads the verb, and is easy to scan. It is concise but could have included a bit more detail without becoming bloated, so it earns a 4 rather than a 5.

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?

This tool has 6 parameters, no output schema, and no annotations, creating a high burden for the description. The description only covers purpose and partial format behavior, omitting parameter details, usage context, and failure modes, making it insufficient for an agent to invoke the tool correctly on its first attempt.

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?

Schema description coverage is only 33% (key and href are documented in the schema). The description adds meaning for the format parameter by naming the output types, but it leaves maxChars, timeoutMs, and pathPrefix entirely unexplained, so it does not compensate for the low schema coverage.

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

Purpose5/5

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

The description clearly states the action ('Fetch docs HTML for a component'), the source ('ui-layouts.com'), and the output formats ('raw_html, plain text, or a main-section snippet'). This distinguishes it from sibling tools like get_source_code and get_component_meta, which have different objects.

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?

The description implies a clear use case: retrieving documentation HTML for a component. However, it does not explicitly mention when to avoid this tool or compare it with alternatives like search_components, so it stops short of full guidance.

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

get_source_codeB

Fetch component source code bundle from https://ui-layouts.com/r/{key}.json (or custom filename), list files and optionally return a specific file content.

ParametersJSON Schema

Name	Required	Description
`maxChars`	No
`timeoutMs`	No
`componentName`	No	Component name (e.g. 'liquid-glass-weather', 'single-img-ripple-effect')

TDQS

B3.1/5.0

Behavior2/5

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

No annotations exist, so the description must fully disclose behavior. It mentions fetching, listing files, and returning content, but omits important traits: it does not explicitly state the tool is read-only, describe error behavior for invalid keys, or clarify the return format. The phrase 'or custom filename' is confusing and not supported by any parameter, adding ambiguity rather than transparency.

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

Conciseness3/5

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

The description is a single sentence, so it is brief and front-loaded with the main action. However, the phrase 'or custom filename' is unclear and undermines the conciseness by introducing an undefined concept. It earns a middle score because it is not overly verbose but is not entirely precise.

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

Completeness2/5

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

Given no output schema and moderate complexity (3 parameters), the description is incomplete. It does not explain how the tool can 'optionally return a specific file content' because there is no parameter to select a file. It also lacks details on the response format and how parameters like maxChars and timeoutMs affect the behavior. The description answers the 'what' but not the 'how' in sufficient depth for an agent to use it correctly.

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?

Schema description coverage is only 33% (only componentName has a description). The description adds a little meaning by connecting componentName to the {key} in the URL, but it does not explain maxChars or timeoutMs. The mention of 'custom filename' creates a false expectation, as there is no filename parameter in the schema. The description fails to compensate for the low schema coverage.

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 a specific action ('Fetch component source code bundle'), defines the resource (source code bundle from a URL), and describes the scope (list files, optionally return file content). It distinguishes itself from sibling tools like get_docs and get_component_meta by focusing on the actual source code.

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?

Usage is implied: use this tool when you need the source code of a component. However, there is no explicit guidance on when *not* to use it, nor any reference to alternatives like get_component_meta for metadata or search_components for discovery. The description provides context but no comparative decision framework.

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

search_componentsB

Search ui-layouts components by name / key / group / tags / href.

ParametersJSON Schema

Name	Required	Description	Default
`q`	Yes	Query for component name/key/group/tags/href
`limit`	No

TDQS

B3.4/5.0

Behavior2/5

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

No annotations are provided, and the description does not disclose behavioral details beyond the basic search action. It does not mention return format, pagination, potential side effects, or any operational constraints, leaving the agent with significant uncertainty about the tool's runtime behavior.

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

Conciseness5/5

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

The description is a single, concise sentence that immediately conveys the tool's purpose. It is front-loaded with the action and resource, and every word adds value.

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?

The tool has a simple schema (2 params, no output schema) and no annotations. The description is sufficient to understand the search intent but lacks specifics about the response structure or any constraints on search behavior, which could be necessary for correct invocation and result interpretation.

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?

Schema description coverage is 50% (q has a description, limit does not). The tool description repeats the fields already listed for q, adding no new semantics, and it offers no explanation for limit or how the search behavior works with multiple fields.

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

Purpose5/5

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

The description clearly states the tool searches for ui-layouts components using specific criteria (name/key/group/tags/href). The verb 'search' and the resource are specific, and it distinguishes itself from retrieval-focused siblings like get_component_meta and get_source_code.

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 implicitly indicates when to use this tool (when searching components by these fields), but it does not explicitly discuss alternatives or exclusion cases. Given the sibling tools, there is no guidance on when to prefer get_docs or get_source_code over this search.

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.

4 tool updatesv0.3.0Aug 6, 2026
- First observedget_component_meta
- First observedget_docs
- First observedget_source_code
- First observedsearch_components

Install Server

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

TDQS

B3.4/5.0

Disambiguation4/5

Each tool targets a distinct resource (search, docs, metadata, source code), but get_docs and get_component_meta both fetch HTML and could be confused without careful reading. The descriptions provide enough clarity to differentiate them in most cases.

Naming Consistency4/5

Three tools follow the get_ prefix pattern, while search_components uses search_ instead. This is a minor deviation from an otherwise consistent snake_case verb_noun convention, making it mostly predictable.

Tool Count5/5

Four tools is an ideal scope for a read-only component lookup server. Each tool serves a clear, non-redundant purpose, and the count feels neither sparse nor overwhelming.

Completeness5/5

The set covers the core workflows for exploring a component library: searching, retrieving docs, accessing metadata, and fetching source code. No obvious gaps prevent users from accomplishing typical tasks.

Maintenance

ActivityInactive

ResponsivenessSyncing

Resources

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Visily UI Design
io.github.visily-app
UI design from prompts, screenshots, and URLs for AI coding agents and theme tokens.
Design Tools AI & Machine Learning Developer Tools
25
21st.dev A
dev.21st
Search 21st.dev UI components & themes, get their code, and generate new ones with 21st AI.
Design Tools Developer Tools AI & Machine Learning
2
mcp BOAuth
com.webflow
AI-powered design and management for Webflow Sites
Content Management Systems Web Scraping Marketing
2138
Searchapi A
io.searchapi
Give AI assistants access to real-time data. Search the web, compare flights, find hotels, and more.
Search Browser Automation Travel & Transportation
6

Related MCP Servers

shadcn MCP Server
Developer Tools Documentation Access
magnusrodseth
F
license
A
quality
D
maintenance
Provides AI assistants with direct access to shadcn/ui components and blocks, enabling real-time fetching of component source code, documentation, and implementation examples.
Updated a year ago (2025-07-22 10:55 UTC)
4
30
4
-
MCP Vue UI Kit Server
Developer Tools Documentation Access
TeodorDre
F
license
Not graded
quality
C
maintenance
Enables AI assistants to access documentation of Vue UI components, including props, events, and slots, for generating correct usage code.
Updated 9 months ago (2025-12-19 22:33 UTC)
7
-
AceternityUI_MCP_Server
Developer Tools Documentation Access
yeshsurya
A
license
A
quality
D
maintenance
Provides access to Aceternity UI component library documentation, enabling AI assistants to browse, search, and retrieve detailed information about components.
Updated a year ago (2025-10-19 07:21 UTC)
3
19
MIT
ui-architect-mcp
Design Tools Developer Tools App Automation
foduucom
F
license
A
quality
C
maintenance
Enables AI assistants to generate production-ready, professional UI design systems and components from simple descriptions, with real images, animated components, and automated quality checks.
Updated 5 months ago (2026-03-30 13:48 UTC)
16
-

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

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/ui-layouts/mcp'

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

@ui-layouts/mcp

📦 Installation & MCP Setup

Requirements

Quick Start

Using with Claude Code (CLI)

🛠️ Tools

🔍 search_components

📘 get_docs

🧩 get_component_meta

💾 get_source_code

💬 Prompts

🎯 find_component

🛠️ implement_component

🔗 Recommended Workflow

⚙️ Server Info

🧠 Example Usage in Cursor / Claude

👤 Author (Naymur & Jinho)

Be A Sponsor

Available Tools

Tool Schema Changelog

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

Latest Blog Posts

MCP directory API

🔍 `search_components`

📘 `get_docs`

🧩 `get_component_meta`

💾 `get_source_code`

🎯 `find_component`

🛠️ `implement_component`