Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@theme-video-mcp Create a 30-second video explaining DNS resolution"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
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.
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)Related MCP server: ClipACanvas
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)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.
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.
Returns the fixed 3D icon names grouped by category (for statement/diagram/hub/etc.) and the flat illustration names (for the outro scene).
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It uses 'Returns' and 'fixed' which imply a read-only, deterministic operation with no side effects. This is sufficient for a simple listing tool, though it does not explicitly state read-only or describe any error conditions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, efficient sentence that front-loads the main output (icon names) and specifies the grouping and special case (outro scene). No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a no-parameter, no-output-schema tool, the description adequately conveys what is returned: icon names grouped by category and illustration names for outro. It does not specify the exact data structure (e.g., list vs map), but given the simplicity, an agent can reasonably infer the expected response. The absence of output schema is offset by the clear enumeration of content.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters, so the schema covers everything vacuously. The description does not need to explain parameters, and the baseline for 0-param tools is 4. It adds no redundant parameter information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states exactly what the tool returns: fixed 3D icon names grouped by category and flat illustration names for the 'outro' scene. It clearly identifies the resource (assets) and differentiates from siblings like list_components (components) and render_video (video rendering) without needing to open schemas.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description makes the purpose clear but does not explicitly state when to use this tool versus alternatives like list_components or render_video. The usage context is implied by the content type, but there is no explicit when-to-use or when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns the fixed catalog of scene components (name, description, default duration, prop schema) that render_video can compose.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses that the catalog is 'fixed' (immutable/static) and that the tool 'Returns' data, which implies a read-only operation. This is meaningful behavioral context beyond a bare listing, though it doesn't explicitly mention auth or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One sentence, front-loaded with the verb, with no redundant words. Every part contributes value: what it returns, the key fields, and the relationship to render_video.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with zero parameters and no output schema, the description is complete: it tells the agent exactly what the catalog contains (name, description, default duration, prop schema) and which consumer it serves. An agent can correctly predict the tool's behavior without additional lookup.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline is 4. The schema already fully defines the absence of parameters, and the description adds no param-specific detail because none is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Returns') and resource ('fixed catalog of scene components'), and it names the exact fields included. It also ties the catalog to render_video, making it easy to distinguish from list_assets.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies when to use this tool: to see what scene components render_video can compose. It does not explicitly exclude alternatives like list_assets, but the reference to render_video provides sufficient context for a zero-parameter catalog query.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Composes the given memo scenes onto the animated squared-paper canvas (camera moves between them) and renders a 9:16 mp4. Uploads it to a temporary host and returns a shareable download URL (videoUrl, kept ~72h) plus the local videoPath and per-scene narration .txt files. No audio is generated.
| Name | Required | Description | Default |
|---|---|---|---|
| title | Yes | Theme / video title. | |
| scenes | Yes | Ordered scenes composed on one sheet. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and does it well: it discloses that no audio is generated, that uploads are temporary (~72h), that it returns both a URL and local paths, and that per-scene narration .txt files are written. This exceeds typical transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the main action, then output details. Every sentence adds value, and the key behavior (no audio) is noted upfront. No redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of the scenes array and the absence of an output schema, the description explains the output format (videoUrl, videoPath, narration .txt) and the temporary host retention. It covers what an agent needs to know to call and use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so both parameters are documented. The description adds context about the output and the purpose of narration (written to .txt, no audio) but does not add new meaning to the parameters themselves beyond the schema. This meets the baseline for high coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool composes memo scenes onto a squared-paper canvas, renders a 9:16 mp4, uploads to a temporary host, and returns a download URL plus local paths. It uses a specific verb (composes, renders, uploads, returns) and a clear resource (scene spec → video), and it is obviously distinct from the sibling list tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage (when you have memo scenes and want a rendered video) but does not explicitly state when not to use it or mention alternatives. However, the siblings are listing tools, so the purpose is unambiguous. A clear 'use this when...' would push it to 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.0list_assetslist_componentsrender_videoScored 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.
Fireship-style short videos from a topic — Remotion motion graphics, word-timed captions, 1080p.
Render video and run AI media tasks from a single declarative JSON request.
Turn URLs, recordings, docs, assets, or ideas into launch films, demo recordings, and decks.
Make animated videos by asking Claude, Cursor or any MCP client. Your AI writes it, we render it.
