What comes back is the design system's own material — navigation, documented examples, component source — plus a screenshot, which is how you check that a story renders the way its docs claim. That combination is what makes it useful to an agent writing UI against components someone else built: find the component that already exists, read the props and examples the team documented, and look at it before copying a pattern. Nothing writes back, so the Storybook stays the source of truth.
A reader for a running Storybook instance: connect to its URL, then browse the navigation, search components, pull documentation and capture a rendering.
- connect takes a Storybook url and returns connection status; its description marks it as required before other tools.
- list walks the Storybook navigation of components and stories, narrowed by category and expanded with full.
- search finds components by name or by path, for when the navigation label and the code path differ.
- get_docs returns documentation, code examples and content for a component or story at a given path, with format and full controlling how much comes back.
- screenshot captures the rendering of a component or story at a path.
A running Storybook the server can reach over HTTP, at the url you hand to connect. No account or key is configured.
One command — npx -y @raksbisht/storybook-mcp