Which integrations are available for this server?

Allows browsing, inspecting, creating, and composing components in a running Storybook instance.

How do I use storybook-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., "@storybook-mcp List all components in Storybook" 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.

storybook-mcp

by stevebrownlee

Overview Schema Related Servers Score Discussions

Python

Local

Storybook MCP Server

An MCP (Model Context Protocol) server that integrates with a running Storybook instance. It lets AI-powered coding tools browse your component library, inspect individual components, and scaffold brand-new components from natural language.

Features

Tool	Description
`storybook_list_components`	List & search every component in your running Storybook
`storybook_get_component`	Get stories, arg types, default args, and Storybook URLs for a component
`storybook_create_component`	Scaffold a component + Storybook story from a plain-English description
`storybook_compose_view`	Compose existing components into a higher-order page/view with layout, state, and wiring

Related MCP server: MCP Design System Extractor

Quick Start

Prerequisites

Python ≥ 3.10
A running Storybook instance (v7+)
uv installed

1. Install uv if needed (Python Package Manager)

# Install via Homebrew
brew install uv

# Or via curl
curl -LsSf https://astral.sh/uv/install.sh | sh

Note: The storybook-mcp package itself does NOT need to be installed separately. The MCP configuration uses uvx which automatically downloads and runs the package when needed.

Configuration by Editor

Configuration Format A: Project-Relative Paths

Use this configuration for Cursor, Windsurf, Roo Code, and Kilo Code.

{
  "mcpServers": {
    "storybook": {
      "command": "uvx",
      "args": ["storybook-mcp"],
      "env": {
        "STORYBOOK_URL": "http://localhost:6006",
        "STORYBOOK_COMPONENTS_DIR": "relative/path/to/your/storybook/components",
        "STORYBOOK_FRAMEWORK": "react",
        "STORYBOOK_STYLE_TECH": "tailwind",
        "STORYBOOK_TYPESCRIPT": "true"
      }
    }
  }
}

Configuration File Locations:

Cursor: .cursor/mcp.json (project root - already created in this project)
Windsurf: .windsurf/mcp.json (project root)
Roo Code: .roo/mcp.json (project root)
Kilo Code: .kilocode/mcp.json (project root)

Configuration Format B: Absolute Paths

Use this configuration for Claude Desktop and Claude CLI.

{
  "mcpServers": {
    "storybook": {
      "command": "uvx",
      "args": ["storybook-mcp"],
      "env": {
        "STORYBOOK_URL": "http://localhost:6006",
        "STORYBOOK_COMPONENTS_DIR": "/absolute/path/to/frontend/src/apps/core/shared/core-components",
        "STORYBOOK_FRAMEWORK": "react",
        "STORYBOOK_STYLE_TECH": "tailwind",
        "STORYBOOK_TYPESCRIPT": "true"
      }
    }
  }
}

Configuration File Locations:

Claude Desktop (macOS): ~/Library/Application Support/Claude/claude_desktop_config.json
Claude CLI (Linux/macOS): ~/.config/claude/claude_desktop_config.json
Claude CLI (Windows): %APPDATA%\Claude\claude_desktop_config.json

Note: Claude Desktop and Claude CLI require absolute paths for STORYBOOK_COMPONENTS_DIR.

Usage Examples

Once configured, you can use natural language commands:

List Components

"List all components in Storybook"
"Show me all button components"

Inspect Component

"Show me the details for the Core/UI/Button component"
"What props does the DataTable accept?"

Create Component

"Create a new AlertBanner component with info, warning, and error variants"
"Build a StatusIndicator component with online/offline/away states"

Compose Page

"Compose a SettingsPage using Sidebar, Tabs, TextInput, Toggle, and Button"
"Build a DashboardView with Card, Chart, DataTable, and Badge components"

Troubleshooting

MCP Server Not Connecting

✅ Ensure Storybook is running at http://localhost:6006
✅ Restart your editor/CLI after creating/modifying the MCP configuration file
✅ Verify uv is installed: uv --version
✅ Check that the configuration file is in the correct location for your tool

Components Not Found

✅ Check that Storybook is fully loaded in browser
✅ Component titles are case-sensitive
✅ Use storybook_list_components to see available components

Available Tools

4 tools

storybook_compose_viewA

Compose existing Storybook components into a higher-order page or view.

Fetches the Storybook component catalog, resolves the requested (or auto-discovered) child components, then scaffolds a new page/view file that imports and wires them together with layout, props, local state, and event handlers. Optionally generates a Storybook story for the view.

Use storybook_list_components first to see what's available, then storybook_get_component to inspect props/args before composing.

Args: params (ComposeViewInput): Validated input containing: - name (str): PascalCase page/view name, e.g. 'DashboardPage' - description (str): Natural-language description of the page - components (Optional[List[ComponentPlacement]]): Explicit component list - layout (Optional[str]): Layout strategy hint - include_state (bool): Generate useState/handlers (default True) - include_story (bool): Generate a story file (default True) - category (Optional[str]): Storybook category (default 'Pages')

Returns: str: Markdown summary with all generated file contents.

ParametersJSON Schema

Name	Required	Description	Default
`params`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.6/5.0

Behavior4/5

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

The description explains that the tool creates new files (scaffolding a page/view and optionally a story), which is a side effect beyond the read-only annotations. It also mentions fetching the catalog (read) and resolving components. The destructive hint is false, which aligns with file creation (reversible). No contradictions and adds context beyond annotations.

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 structured with a clear separation of purpose, process, guidance, args, and returns. It is relatively long but justified by the tool's complexity (nested input, multiple options). Every sentence serves a purpose, and the key info is front-loaded.

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

Completeness5/5

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

Given the tool's complexity (nested ComposeViewInput object, auto-discovery, multiple generation options), the description covers all necessary aspects: what it does, prerequisites (use list/get tools), input parameters with their roles, and output format (Markdown summary). It is fully adequate for an agent to use correctly.

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?

Although the schema already describes parameters well, the tool description's 'Args' section adds value by summarizing each parameter's role in the composition process (e.g., auto-discovery when components are omitted). This helps the agent understand how parameters interact beyond the schema definitions.

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 composes existing Storybook components into a higher-order page or view, detailing the process (fetches catalog, resolves components, scaffolds file). It distinguishes from siblings like storybook_create_component (creates new components) and storybook_list_components (lists components), ensuring no ambiguity.

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?

Explicit guidance is provided: 'Use storybook_list_components first to see what's available, then storybook_get_component to inspect props/args before composing.' This tells the agent exactly how to prepare and when to use this tool relative to siblings.

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

storybook_create_componentA

Scaffold a new component with Storybook story from a natural-language description.

Generates a component file and a corresponding .stories. file based on the configured framework (React/Vue/Svelte), language (TS/JS), and styling approach. Files are written into the configured STORYBOOK_COMPONENTS_DIR.

Args: params (CreateComponentInput): Validated input containing: - name (str): PascalCase component name - description (str): Natural-language description of the component - category (Optional[str]): Storybook hierarchy category - props (Optional[List[PropDefinition]]): Explicit prop definitions

Returns: str: Summary of the generated files with their full contents.

ParametersJSON Schema

Name	Required	Description	Default
`params`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A3.7/5.0

Behavior3/5

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

Annotations indicate destructiveHint=false, but the description does not clarify potential overwrite behavior if a component with the same name exists. It adds that files are written to a configured directory, but lacks details on permissions, side effects, or error handling.

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 about 150 words and front-loaded with a clear one-liner. The Args section is somewhat redundant with the schema but still concise. Minor redundancy keeps it from a 5.

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?

Given the detailed input schema and output schema, the description adequately explains the tool's purpose and output. It mentions the generated files and directory, but lacks information on overwriting behavior and error scenarios.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The description repeats parameter details in an Args section, but the input schema already has comprehensive descriptions for each property (name, description, category, props). Since schema coverage is high, the description adds minimal new meaning beyond summarizing.

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 scaffolds a new component with a Storybook story from a natural-language description. It specifies the generated files (component and story) and differentiates from siblings (compose, get, list).

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 implies the tool is for creating new components, but it doesn't explicitly state when to use it versus alternatives like storybook_get_component or storybook_list_components. No when-not-to-use guidance is provided.

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

storybook_get_componentA

Read-onlyIdempotent

Get detailed information about a specific Storybook component.

Returns every story registered under the given title, including story IDs, arg types, default args, and the direct Storybook URL for each.

Args: params (GetComponentInput): Validated input containing: - component_title (str): Exact component title path, e.g. 'Components/Button' - response_format (ResponseFormat): 'markdown' or 'json'

Returns: str: Detailed component information in the requested format.

ParametersJSON Schema

Name	Required	Description	Default
`params`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4/5.0

Behavior3/5

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

Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true. The description does not add behavioral traits beyond return content. No contradiction but no added value beyond annotations.

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 concise at 5 sentences with clear structure: purpose, return details, parameter listing, and return format. Every sentence adds value.

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?

Given the simple tool (single parameter with nested object) and annotations covering safety, the description is nearly complete. It covers purpose, parameters, and return. Could mention error handling for missing components, but overall sufficient.

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?

Even though schema descriptions exist, the description adds meaningful context with examples (e.g., 'Components/Button') and clarifies the response_format parameter. It improves usability over the schema alone.

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 verb 'get' and resource 'specific Storybook component', and details what is returned (stories, IDs, arg types, URLs). It distinguishes itself from siblings like 'storybook_list_components' which lists all components.

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 implies usage by stating its purpose but does not explicitly clarify when to use this tool versus alternatives like 'storybook_list_components' or 'storybook_compose_view'. No when-not-to-use guidance is provided.

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

storybook_list_componentsA

Read-onlyIdempotent

List all components registered in the running Storybook instance.

Fetches the Storybook index and returns component titles grouped by hierarchy, with their story counts. Optionally filter by a substring.

Args: params (ListComponentsInput): Validated input parameters containing: - search (Optional[str]): Case-insensitive filter substring - response_format (ResponseFormat): 'markdown' or 'json'

Returns: str: Component listing in the requested format.

ParametersJSON Schema

Name	Required	Description	Default
`params`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.2/5.0

Behavior4/5

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

The description adds behavioral details beyond annotations: it fetches the Storybook index, groups by hierarchy, and reports story counts. No contradictions with annotations.

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 well-structured with a summary and bullet points. It is concise but includes some redundancy with schema descriptions.

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

Completeness5/5

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

For a simple list tool with good annotations, the description covers all necessary aspects: what it does, optional filtering, and output format options.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The description restates parameter semantics already present in the input schema. With schema descriptions covering the fields, the description adds minimal new value.

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 lists all components from the running Storybook instance, with optional filtering. It distinguishes from siblings like storybook_compose_view or storybook_create_component by focusing solely on listing.

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 usage for listing components; it does not explicitly state when not to use or mention alternatives, but the sibling names provide enough context for differentiation.

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

Install Server

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

TDQS

A4.2/5.0

Disambiguation5/5

Each tool has a distinct purpose: listing components, getting component details, creating components, and composing views from existing components. No overlap or ambiguity.

Naming Consistency5/5

All tools follow a consistent 'storybook_verb_noun' pattern (list_components, get_component, create_component, compose_view). Convention is uniform and predictable.

Tool Count5/5

With 4 tools, the server covers the essential operations for Storybook without being excessive. The count is well-scoped for its domain.

Completeness4/5

Core operations are covered: discovery, inspection, creation, and composition. Missing update/delete for components, but these are typically handled via filesystem, not Storybook API.

Maintenance

ActivityInactive

ResponsivenessNo issues

Resources

GitHub Repository

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

Tseha AFeatured
io.tseha
Serves your design system and coding standards to coding agents, so they stop guessing.
Developer Tools Documentation Access
93
marmo-ui A
io.github.mahmoudilyan
Live React design-system APIs, patterns, and code validation so AI agents build real UI, not slop.
Design Tools Developer Tools
142
Cypress Cloud MCP B
io.cypress.mcp
Direct access to Cypress tests results and accessibility reports in your AI workflow.
Testing & QA Tools CI/CD & DevOps
24
Indicate A
io.github.indicateio
AI-powered intelligence for your development workflow via Indicate.
Developer Tools Code Analysis
2

Related MCP Servers

Storybook MCP Server
Autonomous Agents Developer Tools
m-yoshiro
A
license
B
quality
D
maintenance
A Model Context Protocol server that integrates with Storybook to help AI tools query UI components and retrieve usage examples from static Storybook files.
Updated a year ago (2025-04-15 23:47 UTC)
2
908
21
MIT
MCP Design System Extractor
Developer Tools Content Management Systems
freema
A
license
A
quality
B
maintenance
Server that enables AI assistants to interact with Storybook design systems. Extract component HTML, analyze styles, and help with design system adoption and refactoring.
Updated a month ago (2026-07-27 15:55 UTC)
9
78
69
MIT
storybook-mcp-server
Design Tools Developer Tools Testing & QA Tools
stefanoamorelli
A
license
Not graded
quality
C
maintenance
An MCP server that enables AI assistants to browse Storybook components, manage stories, inspect props, and capture screenshots of components.
Updated a year ago (2025-09-14 11:23 UTC)
6,360
14
AGPL 3.0
Storybook MCPofficial
Developer Tools Design Tools Documentation Access
storybookjs
A
license
Not graded
quality
B
maintenance
Enables AI agents to interact with Storybook by exposing UI component information and development workflows through the Model Context Protocol.
Updated 13 days ago (2026-08-21 11:28 UTC)
270
MIT

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/stevebrownlee/storybook-mcp'

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

Storybook MCP Server

Features

Quick Start

Prerequisites

1. Install uv if needed (Python Package Manager)

Configuration by Editor

Configuration Format A: Project-Relative Paths

Configuration Format B: Absolute Paths

Usage Examples

List Components

Inspect Component

Create Component

Compose Page

Troubleshooting

MCP Server Not Connecting

Components Not Found

Available Tools

Output Schema

Output Schema

Output Schema

Output Schema

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

Storybook MCPofficial

Latest Blog Posts

MCP directory API