Skip to main content
Glama
marvkr

Better Design

Get Motion Guide

get-motion-guide
Read-onlyIdempotent

Scaffold a brand-aware Remotion product-demo project or fetch video components, motion topics and guidance for building and debugging product videos in code.

Instructions

Load Better Design's video design-system guidance for building a product demo or promo video in code.

Use this before writing a Remotion composition, and while debugging one. It covers the product-demo brief, brand and motion tokens, responsive format profiles, product interactions, captions and accessibility, story and rhythm, layout traps, rendering, and visual review.

Start with scaffold: true. It returns a complete brand-aware Remotion project with landscape and vertical compositions, typed Studio props, a shared timeline, product-interaction scene, sourced proof, captions and an optional generated music bed.

Then pick the product shots from the video components: agent and prompt screens, phone and laptop mockups, cropped screen recordings, terminal sessions, charts and counters, title reveals, captions, logo stings, social proof, transitions and backgrounds. get-motion-guide({}) lists them by group; get-motion-guide({ component: "phone-mockup" }) returns that component's source, prop defaults, natural length and install command. Better Design wrote every one and serves them from its registry, so the shadcn CLI installs them with the video kit they share. plan-video turns a one-line brief into beats with one component each, cut-screen-recording cuts a recording into beats, and render-video-frames renders chosen frames so you check the work.

Install and follow the twelve official Remotion skills from https://www.remotion.dev/docs/ai/skills for current APIs. Better Design owns brand, hierarchy, story, pacing and review. RemotionUI, remocn and Remotion Bits are optional, source-labelled pattern libraries; ask before installing community code and adapt it to the active video tokens.

This tool does not render. Rendering needs Remotion and a large headless-browser download in the user's own project. Write the files into their repo, then use render-video-frames to check chosen frames before the full render.

This complements the design tools: use get-ui-principle for visual decisions and get-ux-principle for product behavior. For in-app animation whose timing the user should tune by eye (durations, springs, stagger), call get-jig-guide and mount its tuning panel instead of guessing values.

You can either:

  1. Get the starter project: get-motion-guide({ scaffold: true })

  2. Get one video component as files: get-motion-guide({ component: "answer-reply" })

  3. Request a known topic: get-motion-guide({ topic: "video-design-system" })

  4. Use an alias: get-motion-guide({ topic: "product demo structure" })

  5. Search for the current task or problem: get-motion-guide({ query: "reflow my product demo for vertical video" })

  6. Get the full topic and component index: get-motion-guide({})

Prefer query search when you do not know the topic name. Use maxTokens to keep responses focused (recommended: 5000-10000).

Input Schema

NameRequiredDescriptionDefault
queryNoNatural language description of the video or animation task or problem.
topicNoSpecific motion topic or alias, e.g. video-design-system, product-demo-brief, formats-and-safe-areas, product-interactions, captions-and-accessibility, remotion-resources, video-components, verifying-a-render.
contextNoOptional. One sentence on WHY you are calling this and what the user asked for (e.g. 'adding nav icons for the fintech dashboard'). Used only for usage analytics; does not change the result.
scaffoldNoReturn a complete brand-aware Remotion product-demo project, as files to write. Start here when building a video.
componentNoA video component name, e.g. answer-reply, prompt-compose, terminal-session, phone-mockup, laptop-mockup, recording-shot, headline-reveal, captions, logo-reveal, stat-count. Returns its source files, prop defaults, natural length and install command.
maxTokensNoMaximum tokens to return for guidance and the index. Truncates content to fit. Recommended: 5000-10000. Ignored by scaffold and component, which always return whole files.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.7/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnly/idempotent/non-destructive, but the description adds substantive traits beyond them: the tool does not render, rendering requires Remotion plus a large headless-browser download in the user's own project, files must be written into the user's repo, and community code should be asked about before installing. It also discloses truncation behavior via maxTokens.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

It is front-loaded and well organized into topic, workflow, and modes, but it is noticeably long and repeats itself: the numbered six-item call list restates scaffold, component, topic, and the empty-call index behavior already stated in the prose above. Registry boilerplate ('Better Design wrote every one and serves them from its registry') adds length without decision value.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a six-parameter, no-output-schema guidance tool, the description covers what each call mode returns (starter project, component source plus prop defaults and natural length, topic guidance, index), the recommended workflow order, and the handoff to plan-video and render-video-frames. Nothing an agent needs in order to call it correctly is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline would be 3; the description goes further by explaining precedence between parameters ('Prefer query search when you do not know the topic name', 'Start with scaffold: true') and by giving concrete examples of topic aliases and component names. It does not deepen the semantics of `context` beyond what the schema states.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Opens with a specific verb and resource: 'Load Better Design's video design-system guidance for building a product demo or promo video in code.' It clearly delineates scope and explicitly contrasts itself with get-ui-principle, get-ux-principle, and get-jig-guide, so an agent can route correctly without schema inspection.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

States timing ('use this before writing a Remotion composition, and while debugging one'), prescribes a starting point ('Start with scaffold: true'), and enumerates six distinct invocation modes with the rule 'Prefer query search when you do not know the topic name.' It also routes adjacent work to plan-video, cut-screen-recording, and render-video-frames.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.