theme-video-mcp
# theme-video-mcp
An MCP that composes a ~30-second tech-illustration video from a **fixed library
of Remotion components**. This is *not* AI video generation — the MCP defines
high-quality components; the calling AI just picks and arranges them.
## Commands
```bash
npm install # install deps
npm run studio # Remotion Studio — live animated preview + timeline
npm run storybook # Storybook — per-component catalog (photo + playable)
npm run render # render the demo composition to mp4 (output/)
npm run mcp # start the MCP server (stdio)
```
## Layout
```
src/remotion/
components/
scenes/ # full scenes (TitleScene, DiagramScene, ...)
primitives/ # building blocks (Box, Arrow, ...)
transitions/ # (to come)
lib/ # theme tokens + animation helpers
registry.jsx # SINGLE source of truth: name -> component + prop schema
Video.jsx # composes a scene spec into a video
Root.jsx # Remotion composition registration
src/mcp/ # MCP server: list_components(), list_assets(), render_video(spec)
src/pipeline/ # render.js (bundle + renderMedia) + upload.js (temp URL)
stories/ # Storybook stories (preview via @remotion/player)
```
## How the pieces connect
The scene vocabulary lives in `src/remotion/lib/scenes.jsx` (`SCENE_KINDS`:
`statement | diagram | hub | example | usage`) and is described as pure data in
`src/remotion/catalog.js`, which the MCP `list_components` tool exposes. A scene
spec is `[{ kind, props, place?, narration? }]`; `PaperVideo.jsx` lays the scenes
onto one paper sheet and choreographs the camera between them.
## Status
Working end-to-end. `render_video` renders the 9:16 mp4, **uploads it to a
temporary host (litterbox, kept 24h by default)** and returns a shareable
`videoUrl` plus the local `videoPath` and per-scene narration `.txt` files. No
audio/TTS (the user adds audio). Pass `upload:false` to `renderVideoSpec` to skip
the upload, or `uploadTime` ("1h"|"12h"|"24h"|"72h") to change retention.
TDQS
Scored across 3 tools
The three tools have clearly separated roles: list_components enumerates scene components, list_assets enumerates available icons/illustrations, and render_video performs the actual rendering. There is no realistic ambiguity between the two list tools because their resource types are distinct.
All tool names follow the same lowercase snake_case verb_noun pattern: list_components, list_assets, and render_video. The verbs 'list' and 'render' are accurate and consistently applied.
Three tools are well-scoped for this narrow server purpose: discover available components, discover available assets, and render a video. Each tool earns its place and there are no redundant or extraneous tools.
The workflow is fully covered: list_components supplies prop schemas for composing scenes, list_assets provides valid asset names, and render_video consumes both to produce the final output with URLs and narration files. Since the catalogs are fixed, additional CRUD operations would be unnecessary.