Problem
When instructing an agent to use for example a button component from storybook mcp, the agent will use the get-documentation tool with the button id.
This works for components that map their id exactly, but for components in folders, this will not work. If button is in a general folder, the id will be general-button, and the get-documentation will therefore fail to get the component.
The agent will then fallback to list-all-documentation, which might include hundreds of other components, increasing token usage significantly and the agent needs to search 'partially' itself, slowing down the process.
Proposed Solution
Introduce a dedicated search-documentation tool that accepts a partial query and returns a lightweight list of matching components, for example for the button:
- Button (general-button): General Button
- FormButton (form-button): Button specifically used in forms
This keeps exact-fetch (get-documentation) and search as distinct operations, easier to optimize each independently. You could even add a limit parameter or minimum match threshold to prevent token bloat when the query matches too many components.
Token Cost
The current fallback to list-all-documentation can return the id's, stories and short description of hundreds of components in one response. If partial search can narrow this down to a handful of results with lightweight metadata, the token savings could be significant.
Open for feedback 🙂
Problem
When instructing an agent to use for example a
buttoncomponent from storybook mcp, the agent will use theget-documentationtool with thebuttonid.This works for components that map their id exactly, but for components in folders, this will not work. If
buttonis in ageneralfolder, the id will begeneral-button, and theget-documentationwill therefore fail to get the component.The agent will then fallback to
list-all-documentation, which might include hundreds of other components, increasing token usage significantly and the agent needs to search 'partially' itself, slowing down the process.Proposed Solution
Introduce a dedicated
search-documentationtool that accepts a partial query and returns a lightweight list of matching components, for example for the button:This keeps exact-fetch (
get-documentation) and search as distinct operations, easier to optimize each independently. You could even add alimitparameter or minimum match threshold to prevent token bloat when the query matches too many components.Token Cost
The current fallback to
list-all-documentationcan return the id's, stories and short description of hundreds of components in one response. If partial search can narrow this down to a handful of results with lightweight metadata, the token savings could be significant.Open for feedback 🙂