storybook-events-inspector
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| catalog | No | Path to a JSON file of { name, tags }[] shape for annotating events (flag: --catalog). Optional; omit and everything is undocumented. | |
| storybook-url | No | The URL of the running Storybook instance (flag: --storybook-url). Set this if your Storybook runs anywhere else; the server won't discover it. | http://localhost:6006 |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| list_storiesA | List every story in the running Storybook, so you can find a story id for open_story without guessing. |
| open_storyA | Load a story by id in a real (headless) browser and start capturing every custom event it dispatches, including any dispatched while the story itself is rendering (e.g. from connectedCallback). Clears any previously captured events, and reports the sinceSeq cursor to use from here on. Call this before click, dispatch_event, or get_events. |
| clickA | Click a real element in the open story via a CSS selector (e.g. a menu trigger) and let the resulting custom event(s) get captured naturally — the same "open the menu, see it respond" loop a human runs by hand. Check what fired with get_events afterward. |
| dispatch_eventA | The reverse direction: fire a synthetic event at the story's rendered custom element (found automatically, not necessarily the canvas's first child), to check it responds the way its docs claim — without a real UI trigger to click. The dispatch itself is also captured, same as anything else, so it shows up in the next get_events call too. |
| get_eventsA | Everything captured in the open story so far, newest last: name, the target that actually dispatched it, its detail, and flags (undocumented/shared/retargeted/notComposed). Pass sinceSeq (from a previous response, or from open_story) to get only what arrived after it; seq numbers increase for the life of the server, so a cursor stays valid across open_story calls. |
| clear_eventsA | Empty the captured-events buffer for the open story without reloading it. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 6 tools
Each tool has a clearly distinct role in the event-inspection workflow: list_stories discovers stories, open_story starts a capture session, click and dispatch_event trigger events from different directions, get_events retrieves captured data, and clear_events resets the buffer. The descriptions explicitly clarify boundaries, such as open_story clearing previous events vs. clear_events emptying the buffer without reloading.
Most tools follow a verb_noun pattern (open_story, list_stories, dispatch_event, get_events, clear_events). The lone exception is click, which is a bare verb, but it remains intuitive and does not disrupt overall consistency.
Six tools is well-scoped for a focused event inspector: discovery, session setup, two interaction modes, retrieval, and reset. Each tool earns its place without redundancy or unnecessary surface area.
The set covers the full inspection lifecycle: discover stories, open one to capture events, trigger events via real clicks or synthetic dispatch, retrieve captured events with cursor support, and clear the buffer. No essential operation is missing, and agents can work around any minor polling needs by calling get_events repeatedly.