Tracking: SB MCP Preview

[JReinhold]

This is a tracking issue for the work required to release the Storybook MCP packages in public preview.

Milestones

Milestone 1: Loose ends

Lead: @JReinhold
Completed by: Week 3, Feb 16

• Improve evals, making them easier to compare before/after results across multiple runs Implement eval orchestrator #136
• Add quality scores to evals based on:
  • Objective:
    • Typescript errors
    • Imported components compared to expected imports
  • Subjective:
    • UI Review
    • Source Review
• Add server instructions #144
• Minimize docs context by only including a subset of stories by default Added a new tool get-component-story-documentation for retrieving specific story documentation #123
• Move the Preview Stories tool to the docs toolset #143
• Improve Preview Stories input to support component ID + story ID from component docs in addition to the current path + story name input
• Add Windows tests to MCP CI
• QA Windows support
• Add more eval metrics:
  • Which MCP tools were called
  • ... with which inputs
  • ... and what was the token count of the output
  • ... optionally comparable to expected values
• Remove the feature.experimentalComponentManifest flag
• MCP Apps follow-up
  • QA in Claude Desktop
  • QA in ChatGPT
• Investigate how to improve server discoverability through registries, packaged extensions, manifests, etc.
• Remove XML formatter

Milestone 2: MCP Test toolset

Lead: @JReinhold
Completed by: Week 4, Feb 23

• Add test tool that allows the agent to run story tests, including getting a11y results
• Prompt Engineering to ensure the agent runs these tests continuously during UI development
• Add quality-focused evals that ensures the testing feature is valuable to agents
  • Modifying existing code
  • Creating new components
  • Both Component Testing and a11y
• Add testing toolset #131
• Addon-Vitest: Add channel API to programmatically trigger test runs storybook#33206

Milestone 3: MCP Composition

Lead: @kasperpeulen
Completed by: Week 2, Feb 9

• Investigate how MCP Composition can work with private/authenticated Storybooks
• Make it possible for users to re-use the Storybook Composition API to compose multiple Storybook sources together in the local MCP
• Support remote, authenticated Storybooks
• Write eval to ensure the agent correctly combines components from different source Storybooks

Milestone 4: Improving React prop types extraction

Lead: @kasperpeulen
Completed by: Week 4, Feb 23

• Replace react-docgen with react-docgen-typescript
• Ensure we have a comprehensive test suite for various ways to type props
• Investigate replacing react-docgen-typescript with a new DYI solution, based on the TypeScript compiler
• Add evals to validate that this is an improvement, eg. using components that are built with forwardRef.

Milestone 5: Documentation

Lead: @kylegach
Completed by: Week 5, March 2

• Usage documentation on @storybook/addon-mcp
• Reference documentation on @storybook/addon-mcp
• Example on how to self-host the MCP server with @storybook/mcp @JReinhold
• Launch material
  • Storybook homepage (/)
  • Storybook feature page (/ai)
  • Blog post
  • E2E video demo @JReinhold

Milestone 6: QA

Completed by: Week 6, March 9

• Docs-driven QA
• Different agents
  • GitHub Copilot
  • Claude Code
  • Codex
  • Opencode
• Different Design Systems, ensuring the manifest generates properly with prop types, stories, etc.

Milestone 7 - Stretch: Expose Component Coverage

Lead: TBD

Would it be valuable for an agent to know, what the test coverage is for a given component, in an attempt at making it write better stories?

This stories-file covers these lines of the component (eg. 80 %)

• How about other modules in the component's module graph?
• How about coverage by other stories files?

Milestone 8 - Stretch: Component Documentation Best Practices

Lead: TBD

What is the best way to document components, both for humans and LLMs to read? Which style is most understandable, how verbose should prop descriptions be, etc.?

Can we take a (design system-like) project and turn it from undocumented to fully documented, and learn from that process?

Can we make a structure around this, exposing an MCP tool/skill that users can use to inject key documentation how-to knowledge into their agent, and then make the agent document all their components?

Resources to learn from:

• https://bennypowers.dev/cem/docs/usage/effective-mcp-descriptions/
• https://bennypowers.dev/cem/docs/usage/documenting-components/