The Webpixels MCP Server enables AI assistants to search, retrieve, and assemble Bootstrap 5 UI components from the Webpixels library.
Search Components (search_components): Find components by name, description, tags, category, or type (component, section, card, screen, layout, page, form, chart), with optional filtering for free components and a configurable result limit.
Get Component (get_component): Retrieve the full HTML code and metadata for a specific component using its UUID or slug (e.g., section-hero-1).
List Categories (list_categories): Browse all available component categories (e.g., Banners, Hero, Pricing, Navbars, Forms, Layouts, Pages) along with component counts, optionally filtered by type.
Assemble Page (assemble_page): Combine multiple components into a complete HTML page by providing an ordered list of component IDs, with options to wrap content in a layout and include Bootstrap CSS/JS assets.
Get Component Dependencies (get_component_dependencies): Explore a component's dependency tree — see what components it depends on, what depends on it, or both directions at once.
Enables searching, retrieving, and assembling Bootstrap UI components from the Webpixels library, allowing for the discovery of components by category or type and the generation of complete HTML pages from individual components.
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., "@Webpixels MCP Server find a hero section and a pricing table for my SaaS landing page"
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.
MCP server for Webpixels Bootstrap 5 components. This server enables AI assistants like Claude to search, retrieve, and assemble Bootstrap UI components from the Webpixels library.
Add to your Claude desktop configuration (~/.config/claude/claude_desktop_config.json on macOS):
{
"mcpServers": {
"webpixels": {
"command": "npx",
"args": ["-y", "@webpixels/mcp"]
}
}
}npm install -g @webpixels/mcpThen add to your configuration:
{
"mcpServers": {
"webpixels": {
"command": "webpixels-mcp"
}
}
}Related MCP server: Basecoat UI MCP
search_componentsSearch Bootstrap components by name, category, type, or description.
Parameters:
query (string): Search query (matches name, description, tags)
type (string): Filter by component type (component, section, card, screen, layout, page, form, chart)
category (string): Category or subcategory slug (e.g., 'sections', 'hero', 'pricing')
is_free (boolean): Filter for free components only
limit (number): Maximum number of results (default: 20)
get_componentGet the HTML code and metadata for a specific component.
Parameters:
id (string, required): Component UUID or slug (e.g., "section-hero-1")
list_categoriesList all component categories with component counts.
Parameters:
type (string): Filter categories by component type
assemble_pageAssemble multiple components into a complete HTML page.
Parameters:
components (array, required): Array of component IDs or slugs in display order
layout (string): Optional layout component ID to wrap the content
includeAssets (boolean): Include CSS/JS links in a full HTML document (default: true)
get_component_dependenciesGet the dependency tree for a component.
Parameters:
id (string, required): Component UUID or slug
direction (string): "dependencies" (what this uses), "dependents" (what uses this), or "both"
The library includes components across several categories:
Components: Banners, Cards, Dropdowns, Headers, Modals, Navbars, Sidebars, Tables, etc.
Forms: Form groups, textareas, form layouts, form examples
Sections: Headers, Hero, Features, CTA, Pricing, FAQ, Team, Testimonials, Contact, Gallery, Logos, Blog, Footers
Layouts: Horizontal, Sidebar, Columns
Pages: Landings, Dashboard, CRUD, Settings, Auth, Profile, Messaging, etc.
User: I need a hero section for a SaaS landing page
Claude: [Uses search_components with query "hero saas"]
[Returns matching hero sections]
User: Show me the code for section-hero-1
Claude: [Uses get_component with id "section-hero-1"]
[Returns HTML and metadata]
User: Create a page with a hero and pricing section
Claude: [Uses assemble_page with components ["section-hero-1", "section-pricing-1"]]
[Returns complete HTML page]npm install
npm run buildnpm startThe component data is generated from the Webpixels library's compiled HTML snippets:
# From the library repository
# Option 1: Generate snippets first, then MCP data
npm run snippets
npm run mcp:generate
# Option 2: All-in-one command
npm run mcp:generate:fullThe script reads compiled HTML from library/snippets/ (not raw .njk files) to ensure all template includes are resolved.
MIT
Assemble multiple components into a complete HTML page. Provide component IDs/slugs in the order they should appear.
| Name | Required | Description | Default |
|---|---|---|---|
| components | Yes | Array of component IDs or slugs in display order | |
| layout | No | Optional layout component ID to wrap the content | |
| includeAssets | No | Include CSS/JS links in a full HTML document (default: true) |
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 assembly function but lacks details on permissions, error handling (e.g., invalid IDs), output format (HTML structure), or side effects (e.g., asset inclusion defaults). This is inadequate for a mutation-like tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the purpose and key parameter usage. Every word contributes to understanding the tool's function without redundancy or unnecessary elaboration.
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 (assembling HTML pages with 3 parameters) and lack of annotations or output schema, the description is incomplete. It does not explain the output (HTML structure), error conditions, or behavioral nuances like default values for 'includeAssets', leaving significant gaps for agent usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents parameters. The description adds minimal value by mentioning 'component IDs/slugs in the order they should appear', which aligns with the schema's 'components' description. No additional syntax or format details are provided beyond the schema.
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 verb 'assemble' and the resource 'multiple components into a complete HTML page', specifying the action and outcome. It distinguishes from siblings like 'get_component' (retrieval) or 'search_components' (searching) by focusing on composition and ordering.
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 mentions component IDs/slugs but does not clarify prerequisites (e.g., components must exist) or compare to other tools like 'get_component_dependencies' for related tasks, leaving usage context implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the HTML code and metadata for a specific component by ID (UUID) or slug.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Component UUID or slug (e.g., "section-hero-1") |
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 retrieves data ('Get'), implying a read-only operation, but doesn't clarify permissions, rate limits, error handling, or what 'metadata' includes. This leaves significant gaps in understanding the tool's behavior beyond basic retrieval.
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 front-loads the purpose ('Get the HTML code and metadata') and specifies the key detail (by ID or slug). There is no wasted verbiage, making it highly concise and well-structured for quick comprehension.
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 low complexity (single parameter, no output schema, no annotations), the description is adequate for basic understanding but incomplete. It doesn't explain the return format (e.g., structure of HTML and metadata) or potential errors, which could hinder effective use despite the simple schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, with the parameter 'id' well-documented in the schema as accepting UUIDs or slugs. The description adds minimal value by reiterating this in parentheses, but doesn't provide additional context like format examples beyond what's in the schema, meeting the baseline for high coverage.
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 action ('Get') and the resource ('HTML code and metadata for a specific component'), specifying it retrieves both code and metadata. It distinguishes from siblings like 'search_components' by focusing on a single component, but doesn't explicitly contrast with 'get_component_dependencies' which might share similar retrieval aspects.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by specifying retrieval by 'ID (UUID) or slug', which suggests when to use this tool (for known identifiers) versus alternatives like 'search_components' (for broader queries). However, it lacks explicit guidance on when not to use it or direct comparisons to siblings, leaving some ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the dependency tree for a component. Shows what other components it uses or what components use it.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Component UUID or slug | |
| direction | No | Direction: "dependencies" (what this uses), "dependents" (what uses this), or "both" |
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 'Shows what other components it uses or what components use it,' which hints at read-only behavior but doesn't explicitly confirm it's non-destructive or detail response format (e.g., tree structure, pagination). For a tool with no annotations, this leaves significant gaps in understanding its 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 concise with two sentences that efficiently convey the core functionality. It's front-loaded with the main purpose ('Get the dependency tree for a component') and follows with clarifying details. There's no wasted text, though it could be slightly more structured for clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (2 parameters, no output schema, no annotations), the description is adequate but incomplete. It covers the purpose and basic parameter semantics but lacks behavioral details (e.g., read-only confirmation, response format) and usage guidelines. With no output schema, the description should ideally hint at return values, which it doesn't, leaving gaps for an 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?
Schema description coverage is 100%, so the schema already documents both parameters ('id' and 'direction') with descriptions and enum values. The description adds minimal value beyond the schema by mentioning 'dependency tree' and 'what other components it uses or what components use it,' which loosely maps to parameters but doesn't provide additional syntax or format details. Baseline 3 is appropriate when the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Get the dependency tree for a component' specifies the verb ('Get') and resource ('dependency tree for a component'). It distinguishes from siblings like 'get_component' (which retrieves component details) and 'search_components' (which searches for components) by focusing on dependency relationships. However, it doesn't explicitly contrast with 'assemble_page' or 'list_categories', leaving some room for improvement.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for viewing dependency trees, but lacks explicit guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing a valid component ID) or compare with siblings like 'get_component' for general component info. The context is clear but incomplete for optimal agent decision-making.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all component categories with component counts. Useful for understanding what types of components are available.
| Name | Required | Description | Default |
|---|---|---|---|
| type | No | Filter categories by component type |
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 mentions 'component counts' as part of the output, which adds some context beyond basic listing. However, it lacks details on permissions, rate limits, pagination, or error handling that would be important for a read 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 two concise sentences that are front-loaded with the core functionality and followed by a brief usage hint. Every word earns its place with no redundancy or unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read tool with one optional parameter and no output schema, the description is adequate but minimal. It covers the basic purpose and hints at utility, but lacks details on output format, error cases, or integration with sibling tools that would make it more complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with the single parameter 'type' documented as 'Filter categories by component type'. The description doesn't add any parameter details beyond what the schema provides, so it meets the baseline for high schema coverage without compensating value.
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 verb ('List') and resource ('all component categories with component counts'), making the purpose specific and understandable. It distinguishes from siblings like 'get_component' or 'search_components' by focusing on categories rather than individual components, but doesn't explicitly contrast them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context ('Useful for understanding what types of components are available'), suggesting when this tool might be helpful. However, it doesn't provide explicit guidance on when to use this versus alternatives like 'search_components' or what scenarios warrant filtering by type.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search Bootstrap components by name, category, type, or description. Use this to find components that match specific criteria.
| Name | Required | Description | Default |
|---|---|---|---|
| query | No | Search query (matches name, description, tags) | |
| type | No | Filter by component type | |
| category | No | Category or subcategory slug (e.g., 'sections', 'hero', 'pricing') | |
| is_free | No | Filter for free components only | |
| limit | No | Maximum number of results to return (default: 20) |
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 mentions the search functionality but lacks details on permissions, rate limits, pagination (beyond the 'limit' parameter), error handling, or the format of search results. For a search 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 concise and front-loaded, consisting of two sentences that efficiently convey the tool's purpose and usage. Every sentence earns its place without redundancy or unnecessary elaboration.
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 of a search tool with 5 parameters, no annotations, and no output schema, the description is incomplete. It doesn't explain the return values, result ordering, or behavioral aspects like search matching (e.g., partial vs. exact). The description should do more to compensate for the lack of structured data.
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 description adds minimal value beyond the input schema, which has 100% coverage. It lists searchable fields ('name, category, type, or description'), but the schema already describes each parameter in detail. The baseline is 3 since the schema does the heavy lifting, and the description doesn't provide additional syntax or format details.
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: 'Search Bootstrap components by name, category, type, or description.' It specifies the verb ('Search') and resource ('Bootstrap components'), but doesn't explicitly differentiate from sibling tools like 'get_component' or 'list_categories' beyond the search 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 implied usage guidance: 'Use this to find components that match specific criteria.' It suggests when to use this tool (for searching with criteria) but doesn't explicitly state when not to use it or mention alternatives like 'get_component' for retrieving a single component or 'list_categories' for browsing categories without search.
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.0assemble_pageget_componentget_component_dependencieslist_categoriessearch_componentsScored across 5 tools
Each tool has a clearly distinct purpose with no overlap: assemble_page builds pages, get_component retrieves a single component, get_component_dependencies shows relationships, list_categories provides category overview, and search_components finds components. The descriptions make the boundaries explicit, eliminating any ambiguity.
All tool names follow a consistent verb_noun pattern with snake_case: assemble_page, get_component, get_component_dependencies, list_categories, and search_components. The verbs (assemble, get, list, search) are appropriately chosen and applied uniformly throughout the set.
With 5 tools, this server is well-scoped for managing Bootstrap components, covering key operations without bloat. Each tool earns its place by addressing distinct aspects like retrieval, assembly, search, categorization, and dependency analysis, making the count ideal for the domain.
The tool set provides strong coverage for browsing, retrieving, and assembling Bootstrap components, with no dead ends. A minor gap exists in update or creation operations (e.g., edit_component or create_component), but agents can effectively work with the available read-focused tools for most use cases.
Find UI components and themes, retrieve code, and generate with hosted 21st AI when enabled.
Search and pull 500+ production-ready React + Tailwind sections and elements
Generate, inspect, and manage Flowstep UI designs directly from your AI assistant.
Web search, browser automation, scraping, crawling and CAPTCHA solving for AI agents.
