Add manifestProvider option to allow custom manifest retrieval

[Copilot]

Summary

This PR adds an optional manifestProvider function to the @storybook/mcp package, allowing consumers to define custom logic for retrieving component manifests instead of relying solely on HTTP fetch.

Motivation

Previously, the MCP server could only get manifests via HTTP using the built-in fetch API. This created unnecessary complexity when working with local files during development, as demonstrated in serve.ts which had to spin up an HTTP endpoint just to serve local fixture files to itself.

Changes

API Enhancement

The handler now accepts a StorybookContext object with optional manifestProvider:

interface StorybookContext {
  source?: string;
  manifestProvider?: (source: string) => Promise<string>;
}

When provided, the manifestProvider function is called instead of fetch to retrieve manifests. The function receives the source URL/path and should return the manifest content as a string. If not provided, the implementation falls back to using fetch as before.

Implementation Details

• src/index.ts: Updated to use StorybookContext directly for options (removed duplicate StorybookMcpHandlerOptions type)
• src/types.ts: Extended StorybookContext interface with manifestProvider
• src/utils/get-manifest.ts: Renamed from fetch-manifest.ts, updated to use custom provider when available, with fallback to fetch
• src/tools/*.ts: Updated both tools to pass manifestProvider through to getManifest()

Terminology Changes

All "fetch" terminology has been changed to "get" throughout the codebase to better reflect that manifests can be retrieved in any way (not just via HTTP fetch):

• Function: fetchManifest() → getManifest()
• Error class: ManifestFetchError → ManifestGetError
• Files: fetch-manifest.ts → get-manifest.ts

Simplified Development Server

The serve.ts file now demonstrates the cleaner approach:

const storybookMcpHandler = await createStorybookMcpHandler({
  source: './fixtures/full-manifest.fixture.json',
  manifestProvider: async (source) => {
    return await fs.readFile(source, 'utf-8');
  },
});

This eliminates the need for the HTTP endpoint that previously served local fixtures.

Testing

• Added 6 new comprehensive tests for manifestProvider functionality
• All 53 tests passing with 90%+ code coverage maintained
• Manually verified the development server works correctly with the new approach
• CodeQL security analysis passes with 0 alerts

Backward Compatibility

This is a fully backward-compatible change. Existing code continues to work without modification, as manifestProvider is optional and defaults to using fetch.

Original prompt

the handle creator in @storybook/mcp needs to take in an optional manifestProvider?: (source: string) => string option. it should be used to consumers can define their own way of getting the manifest, instead of only using fetch. it should fallback to just fetch.

add this functionality, and also make the serve.ts file use it as a simpler way to get the local manifests.

[Chronological Review: The conversation began with the user requesting an enhancement to the handle creator in the @storybook/mcp package. The user specified that the enhancement should include an optional `manifestProvider` function to allow consumers to define their own method for obtaining manifests, with a fallback to the default fetch method. The user also requested that the serve.ts file utilize this new functionality for easier access to local manifests.]

[Intent Mapping:

• User Request 1: "the handle creator in @storybook/mcp needs to take in an optional manifestProvider?: (source: string) => string option."
• User Request 2: "it should be used to consumers can define their own way of getting the manifest, instead of only using fetch."
• User Request 3: "it should fallback to just fetch."
• User Request 4: "add this functionality, and also make the serve.ts file use it as a simpler way to get the local manifests."]

[Technical Inventory:

• Package: @storybook/mcp
• Functionality: Optional manifestProvider function for custom manifest retrieval.
• Fallback Mechanism: Default fetch method for obtaining manifests.
• File: serve.ts, which needs to be modified to utilize the new manifestProvider functionality.]

[Code Archaeology:

• File: serve.ts
• Functionality discussed: Integration of the new manifestProvider option into the existing codebase for easier local manifest retrieval.]

[Progress Assessment:

• Completed: User has clearly defined the requirements for the new functionality.
• Pending: Implementation of the manifestProvider option and modifications to serve.ts.]

[Context Validation: All necessary details for implementing the requested changes are captured, including the need for fallback functionality and integration into serve.ts.]

[Recent Commands Analysis:

• Last Agent Commands: The user requested the addition of the manifestProvider option and its integration into serve.ts.
• Tool Results Summary: No specific tool results were generated as the conversation focused on user requests and requirements.
• Pre-Summary State: The agent was actively discussing the implementation of the manifestProvider functionality and its integration into the serve.ts file when the token budget was exceeded.
• Operation Context: The commands were executed in the context of enhancing the @storybook/mcp package to provide more flexible manifest retrieval options for consumers.]

1. Conversation Overview: - Primary Objectives: - "the handle creator in @storybook/mcp needs to take in an optional `manifestProvider?: (source: string) => string` option." - "it should be used to consumers can define their own way of getting the manifest, instead of only using fetch." - "it should fallback to just fetch." - "add this functionality, and also make the serve.ts file use it as a simpler way to get the local manifests." - Session Context: The user is enhancing the handle creator in the @storybook/mcp package to allow for custom manifest retrieval methods. - User Intent Evolution: The user has consistently focused on improving the flexibility of manifest retrieval while ensuring a fallback mechanism is in place.

2. Technical Foundation:

• Package: @storybook/mcp
• Functionality: Optional manifestProvider function for custom manifest retrieval with a fallback to fetch.

3. Codebase Status:

• File Name: serve.ts
• Purpose: To be modified to utilize the new manifestProvider functionality for easier access to local manifests.
• Current State: Pending modifications to integrate the new functionality.

4. Problem Resolution:

• Issues Encountered: None explicitly stated; focus is on implementing new functionality.
• Solutions Implemented: Not applicable yet as the implementation is pending.
• Debugging Context: No ongoing troubleshooting efforts mentioned.
• Lessons Learned: The need for flexibility in manifest retrieval methods.

5. Progress Tracking:

• Completed Tasks: User has defined the requirements for the new functionality.
• Partially Complete Work: Implementation of the manifestProvider option and modifications to serve.ts are pending.
• Validated Outcomes: None yet, as the implementation has not been completed.

6. Active Work State:

• Current Focus: Implementing the manifestProvider functionality in the @storybook/mcp package.
• Recent Context: The user has been discussing the specifics of the manifestProvider option and its integration into serve.ts.
• Working Code: No specific code snippets were provided yet.
• Immediate Context: The user was detailing the requirements for...

Created from VS Code via the GitHub Pull Request extension.

---

✨ Let Copilot coding agent set things up for you — coding agent works faster and does higher quality work when set up for your repo.

[changeset-bot]

🦋 Changeset detected

Latest commit: 531a2d4

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 2 packages

Name	Type
@storybook/mcp	Patch
@storybook/addon-mcp	Patch

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[JReinhold]

@copilot we should change the wording of the code from "fetch" to "get", because now it could be any way to get the manifest, and "fetch" is just the callback. do this for all the filenames, function names, etc.

[Copilot]

@copilot we should change the wording of the code from "fetch" to "get", because now it could be any way to get the manifest, and "fetch" is just the callback. do this for all the filenames, function ...

Changed all "fetch" terminology to "get" throughout the codebase. This includes:

• File renames: fetch-manifest.ts → get-manifest.ts
• Function rename: fetchManifest() → getManifest()
• Error class: ManifestFetchError → ManifestGetError
• Updated all imports, comments, and documentation

Commit: 8e538fe

[pkg-pr-new]

npm i https://pkg.pr.new/@storybook/addon-mcp@32

npm i https://pkg.pr.new/@storybook/mcp@32

commit: 531a2d4