[RFC] Add support for a Model Context Protocol (MCP) server integration

[jfrazier08]

Summary

Proposal: Add support for a Model Context Protocol (MCP) server integration in Storybook. This would enable Storybook to expose structured, machine-readable context from stories and documentation, allowing AI systems and developer tools to generate UI code and designs more effectively.

Problem Statement

• Our team is building a prompt-based workflow that allows users to generate UI designs and code using context from design and development tools.
• Figma supports this via an MCP server, which provides structured design context to AI models.
• Storybook currently lacks an MCP server integration, making it difficult to extract structured context—especially from canvas-rendered stories.
• We attempted to rewrite Storybook docs to be compatible with our Backstage MCP server, but canvas content requires a full rewrite, which is not scalable.

Non-goals

• This proposal does not aim to change how Storybook renders or structures stories.
• We are not proposing changes to Storybook’s UI or documentation format.
• We are not requesting a Backstage-specific integration—this should be a general-purpose MCP server for Storybook.

Implementation

We propose the development of a native MCP server integration for Storybook that exposes structured context from stories and documentation. This would include:

• Story metadata (e.g., title, component, args, parameters)
• Documentation content (MDX or auto-generated)
• Component source code and controls

This MCP server would expose a REST or GraphQL API that conforms to the Model Context Protocol specification, enabling AI systems to query and consume Storybook content as structured context for generation tasks.

High-Level Architecture
Introduce a new @storybook/mcp-server package.
This package runs alongside Storybook and exposes an MCP-compliant API endpoint (e.g., /mcp) that returns structured story data.
The server would hook into Storybook’s internal APIs to extract:

• Story metadata
• Docs content (parsed MDX or auto-generated)
• Source code and controls

Prior Art

• Figma’s MCP server provides structured design context for AI workflows.
• Backstage’s TechDocs and catalog plugins expose structured metadata for developer portals.
• Tools like Ladle and Chromatic have explored structured story metadata for automation and testing.

Deliverables

1. Create @storybook/mcp-server package.
2. Implement MCP-compliant API to expose story metadata and docs.
3. Add configuration options for customizing exposed data.
4. Provide documentation and integration examples for AI and developer tools.

Risks

1. Exposing internal story data may introduce security or privacy concerns if not properly scoped.
2. Maintaining compatibility with evolving Storybook internals could increase maintenance burden.

Mitigations:

1. Allow opt-in configuration for exposed data.
2. Use existing Storybook APIs where possible to reduce coupling.

Unresolved Questions

• Using a to do list makes it easy to resolve the questions as we move the RFC along.

• Should the MCP server be a standalone service or a plugin within the Storybook runtime?

• What authentication or access control mechanisms should be supported?

Alternatives considered / Abandoned Ideas

1. Rewriting Storybook docs for Backstage MCP: Too labor-intensive and not scalable.
2. Scraping Storybook output: Fragile and lacks structured data.
3. Embedding Storybook in Backstage: Doesn’t solve the need for structured, queryable context.

[domyen]

Interesting! Thanks for writing this all down.

btw What is Backstage and how is it relevant to Storybook?

[jfrazier08]

Backstage.io is an open source platform for building developer portals (https://backstage.io/). We attempted to extract our Storybook docs to expose them through the portal so our MCP server integration could find context around our design system, however that path wasn't viable due to the fact that we would need to rewrite our entire Storybook site to match the docs format Backstage expects.

[Sidnioulz]

Backstage is likely the most popular Internal Developer Platform, it's commonly used by backend teams to centralise access to services and their documentation.

[zol]

Thanks for submitting @jfrazier08 , I'd be stoked to help enable agentic workflows with an MCP server. The requirements are shaping up but there are still lots of unknowns. For instance, you mention exposing source code from the MCP server. Do you envisage the MCP client does not already have access to the component and story source code?

It would be helpful if you could share some prompts along with the agent behavior that you'd like to see enabled by a Storybook MCP server!

[Sidnioulz]

Do you envisage the MCP client does not already have access to the component and story source code?

One might be integrating components downloaded from NPM into a product, where LLMs would find it less clear and/or more costly to read a transpiled JS bundle than to have endpoints for individual components (or even fail to find the bundle).

In that use case, I imagine integration examples are a lot more valuable than full source, but stories aren't complete examples if the whole chain of decorators (and underlying changes to e.g. preview-head) isn't made available, or if they're too poorly written to really showcase API and expected inputs for all props. That's where providing source as an extra resource could help. LLMs can choose to use the resource if they can't make enough sense of the tool's response to generate working code.

You might also find that most models immediately hog the source and end up with a larger context window than with just the MCP tool's output and don't generate better code. I have no clue where to find relevant datasets to evaluate that though.

But it would surely make it harder to use a MCP server for a deployed Storybook instance as that source info would need to be carried over somehow.

[dannyhw]

I think it would be cool if the storybook dev server basically had some remote mcp endpoints and had stuff like

• get the preview canvas output (html and all)
• get status of a story, and any errors etc
• navigate to story
• get story list
• screenshot story

I started doing some simpler stuff in my own mcp server but tighter integration is needed to do some of the more useful stuff
https://github.com/dannyhw/mcp-storybook

however the playwright mcp together with a simple mcp like this can already navigate storybook pretty well, take screenshots and check console output etc

[JReinhold]

For anyone landing here, we're starting a research project about using agents with Storybook and/or design systems: #32276

Feel free to leave thoughts, feedback or input in there if you want to.

[Sidnioulz]

This MCP server would expose a REST or GraphQL API that conforms to the Model Context Protocol specification, enabling AI systems to query and consume Storybook content as structured context for generation tasks.

What do you mean by this? Do you mean it should be available as a remote MCP, or do you mean the tools should be designed to mimic REST APIs?

If the latter, I've often read that MCPs perform better when they target specific tasks rather than let LLMs figure out which API endpoints to call in what order; both because they communicate usages better and because providing endpoints for specific needs can reduce the number of requests needed.

[dannyhw]

my assumption is that it would a remote mcp because storybook already has a server running that could expose an mcp endpoint this would be simpler than having a local mcp interact somehow with an already running storybook
(i'm not working on this, its just my thoughts on it)

[Sidnioulz]

Here's my own MCP wishlist as a design system practitioner :)

Fetching documentation

Use cases:

• Understanding team conventions for codegen
• Extracting team conventions and onboarding knowledge to create an AGENTS.md-like file
• Understanding environmental requirements for code to run properly (CDNs, external assets, auth walls, etc)

Endpoints:

• List all the MDX docs available
• Fetch a specific doc page
• RAG endpoint: get a prompt from the LLM, identify relevant docs, fetch it in one go, augment prompt (I believe this may be needed when a LLM is looking for documentation explaining a runtime error)

Listing components

Use cases:

• Understanding what's available when implementing a UI/design prompt
• Finding discrepancies between a component library's content and a third-party list (e.g. Figma, docs, other library)

Endpoints:

• List all the components (title, tags, argTypes, semantic usage description)

One of the potential areas for improvement I see in Storybook is encouraging developers to provide structured data on the semantics of their components. How many users use the docs description parameter (which is kinda cumbersome to reach)? And even if they did, how would a poor MCP server fetch parameters for all stories or all CSF metas without running into the performance issues of old? Shouldn't that semantic description be available more globally as structured data to support AI workflows?

Understanding how to use a component

Use cases:

• Once I know I want to use a component, understand its props and how to correctly call it

Endpoints:

• Get component info (all stories objects, complete with args, decorators, tags, etc., component meta including inferred argTypes and/or TS iface, maybe MDX pages if any is written in the same title namespace as the component)
• Get componentS info (same, but multiple components in one query)

The only way this is better than source code is if we provide all the metadata relevant for integration (decorators, args mappings, render functions), specifically because this is what LLMs can't get out of source with a single query. A LLM would need to read file source, do a FS search to find where the file is imported, and read several such files to understand how to integrate a component that has implicit dependencies. A well-written story showing how to use a component in situ would provide all of that in a single query.

The MCP server also has an opportunity to provide governance-related context through story descriptions and tags: something's unstable, or outdated, or known to be buggy. A specific example shows controlled vs uncontrolled usages. Another story shows best practice / conventions when integrating with a specific type of state store, etc.

Even when LLMs do have access to code, MCP endpoints could hint that LLMs can get an overview of how all components work with fewer queries. In workflows like https://southleft.com/insights/design-systems/introducing-story-ui-accelerating-layout-generation-with-ai-mcp/, I suspect it's more efficient to have a single endpoint providing integration snippets for multiple components than to read each component's source code, saving credits and CO2.

QA workflows - design sync

Use cases:

• Find discrepancies between Storybook and Figma component (anatomy, API, variants, tokens, visual output)
• Check if a component is using the right design tokens

Endpoints:

• Compare to design, maybe as a MCP prompt rather than tool? Should already be given a Figma/Penpot MCP output by the user/agent, call get_component_info and fetch the source code, and then find how the design and code differ in terms of API differences (and whether these are expected to be artefacts of how Figma/Penpot work, e.g. focus/hover state variants), anatomy (anything missing? any significant discrepancies in how components are cut up that could lead to issues?), use of design tokens
• Compare visual outputs, I'd keep that separate because it'd need to use the Figma/Penpot API to produce an image export, the Chromatic API to produce a screenshot, and the agent needs to have serious visual analysis capabilities; this is likely useless to most agents and likely harder to build than the rest

QA workflows - Storybook

Use cases:

• Find parts of a component's API that aren't well documented in Storybook
• Scaffold a CSF file for an existing component

Endpoints:

• A prompt template that contains a summary of what a good story is, reminds the LLM about the latest CSF format (therefore avoiding the typical issue of LLMs being outdated), lists typical aspects of a component that go into stories vs interactive stories vs tests, and asks the LLM to scaffold a CSF file with all relevant stories/endpoints

This would need to be tested in e.g. Cline's plan mode as I expect it would also be very useful for end users to clarify what they want documented or to provide descriptions themselves once stories are written.

This could also be an excellent way to encourage the writing of descriptions on all stories, which is relevant for many other MCP workflows.

QA workflows - general quality

Use cases:

• Find potential quality issues in a component's API (argTypes) or implementation
• Find accessibility issues in the code

Endpoints:

• Likely a prompt template that focuses on specific aspects of component implementation and provides relevant context from Storybook to the LLM, leading to...

Storybook augmentation with LLM outputs

Use cases:

• Analyse potential a11y issues in code that aren't visible to Axe, maybe using RAG with curated a11y expert knowledge (talk to TJ about how he built the Design System MCP?), and report those issues so that Storybook can store/cache them and display them as a new test provider

This might not MCP territory any more, this is more of a built-in AI feature I'd like to have. Likewise, if test providers can intersect with AI outputs, TJ's DS MCP could be useful to all Storybook users. Or a MCP server could provide a tool that takes a generic LLM output with a list of issues and/or successes and transforms it into a test provider output.

I think this would only be useful if outputs can be made to persist and can be reviewed/edited by human users or agents though. Some LLMs could analyse code and act as test providers while others could query a Storybook instance for issues and pick up work to do.

[yngvebn]

I would love for an MCP server that provides copilot with a11y violations in a structured LLM format, so that Copilot can help resolve the issues in the context of VSCode or other editors. This would be an excellent addition to our accessibility workflow!