Skip to main content
Glama

Showoff.dev – AI Mockup Generator

Create a launch video

create_launch_video

Creates a cinematic, music-synced launch video for an app or web product in the style of the Showoff trailer: a 9:16 Reel (1080×1920, about 30–45 s), a 16:9 film for websites (format), or a 12–30 s teaser of one to three blocks without an end block. Use it whenever the user wants a launch video, Reel or teaser; use create_project for still images, App Store sets or a free-form animated film, and update_launch_video to change an existing video. Write the story first, then compose blocks in order (every block type is explained in blocks): a video always opens with a device, every move lands on the beat of the song, and the hero lands on the drop unless another block has on_drop. Transitions never cut or dissolve; leave them out for the natural ones. Lines are 2–4 words, written natively in the language of the video; the end card is the brand name slamming into its web address (merge_into). Without blocks you get the standard film from lines and tagline. Read the guide section "Launch videos" first. Screenshots go into named slots: pass URLs, or run the returned curl commands for files on disk. Returns the render page, where the video renders in the user's browser, and what is still missing.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
lookNo"dark" (default): the trailer, devices out of the dark, light in the accent color. "light": friendly and bright, a light gradient background that opens up on the drop, dark text.
loopNotrue: no end card — after the last block everything glides back into the very first frame (camera, the hero phone, its first screen, the background), so the video loops seamlessly from the start, the way Reels and TikToks replay; it ends on a full phrase of the song. Leave out the `end` block; the last block must still show the device of the hero (continue on it with navigate, or let a duo or trio fly in around it). Best with a hero style whose first frame is a moment of its own — zoom, fall, slide, wake. false goes back to an ending.
nameYesThe app name.
linesNoOnly without `blocks` (the standard film): two or four lines — every block takes two or none, so one or three are rejected —, at most 24 characters each, one row each. Lines 1 and 2 are the hero — the first quiet in the intro, the second on the drop; lines 3 and 4 go over the next screen of the same phone, which comes in the way the app changes screens (navigate). The two phones after it stand without text.
storyYesRequired when creating: the ONE story this video tells, in two to four short sentences a stranger remembers after one watch — the hook, how the product gets there, what you end up with. The Showoff trailer: "Your screenshots, shot like products. Right in your browser — or just ask your AI. Ready to launch." Write it first; then every block tells the next part of it in its two lines, in order. A row of unrelated claims is not a story. Speak to the people the app is for (who they are, what they get now) and claim only what is true — never "every model" or "all colors" unless it literally is so.
accentNo#rrggbb brand color for glow and light. Default: the accent color of the first screenshot.
blocksNoThe composition, in order — see the guide ("Launch videos"). Leave it out for the standard film built from `lines` and `tagline`.
deviceNoThe device of every block without its own `device` (default iphone-17-pro). Phones only for real apps — and always an iPhone unless the user explicitly asks for another model, also for Android screenshots (the phone redraws its own status bar). For a web product take a MacBook ("macbook-pro-16") or "browser".
folderNoOnly when the user names a folder: the folder in their Showoff projects to put this in, e.g. "Launch videos" or a subfolder "Showoff/Trailer" (two levels at most). Folders are found by name and created when missing. "" moves it back to the top level.
formatNo"9:16" (default): a Reel for Instagram, TikTok and Shorts — phones and apps. "16:9": landscape for videos that are mostly a MacBook, a website or browser windows (YouTube, a landing page, X): the whole screen fits, pages are never cut off in a close-up.
taglineNoOnly without `blocks`: a small line under the name on the end card of the standard film. Best left out — the review flags it (end-card-claim): a line under the name makes the end slow and small. For the name slamming into the web address, compose `blocks` with an `end` block and `merge_into`.
variantNoFinish of the video's device (list_devices).
music_urlNoPublic URL of the song (MP3, M4A, WAV, OGG, FLAC; up to 25 MB).
backgroundNolight look: the gradient, top to bottom, as #rrggbb colors, e.g. ["#b0aff1", "#f7c6de"] (lavender to pink). Default: two pastel tones from the accent. Pass [] to go back to the default.
music_dropNoExact second of the drop the hero lands on (snapped to the nearest beat) — when the detected drops miss the moment the chorus kicks in. Overrides music_start. A drop only a few seconds into the song is fine: the entrance before it is shortened to fit (the report says so).
status_barNoEvery phone already draws its own clean status bar (9:41, full signal, full battery) over its screenshot. true also puts one over tablet screenshots.
music_startNoSecond in the song around which the video should start — it snaps to the nearest detected drop. Default: the strongest drop with enough music after it.
screenshotsNoScreenshots by public URL (or tiny base64), each into a slot of the blocks. Without `slot` they fill the slots in the order of the film. Files on disk: leave this out and run the returned curl commands.
music_impactNoOnly with an `end` block that has `merge_into` (a teaser without an end card ignores it): second in the song where the end card slams its title into merge_into — e.g. the next drop after the hero, or the last hit of a chorus (snapped to the nearest beat). Every block without its own `beats` stretches or shrinks to land it exactly. Pick it from `music.structure` (get_launch_video). Can be set before the song is uploaded; null removes it.
project_nameNoWhat the user finds this video by in their projects, next to their other videos: "<product> · <what it shows>", e.g. "Tempo · Launch video, drag and drop" or "Showoff · Reel, before and after". Default: "<name> – Launch" — give it whenever the user has or makes more than one video of the product.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.5/5.0
Behavior4/5

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

Annotations only declare readOnly=false, destructive=false, openWorld=false; the description adds real behavior beyond that: the render happens in the user's browser, the call returns a render page plus what is still missing, screenshots can be passed as URLs or via returned curl commands for disk files, and omitting `blocks` falls back to a standard film. It does not discuss authentication or limits, but for a creative-generation tool the disclosure is well above the annotation floor.

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

Conciseness4/5

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

Front-loaded correctly: purpose, formats, then routing to siblings, then composition rules, then return value. It is dense and long, and a few clauses (e.g. the drop/beat rules) duplicate things the schema also explains, but nearly every sentence carries actionable instruction rather than filler.

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

Completeness4/5

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

For a 20-parameter, deeply nested creative tool with no output schema, the description covers the workflow (story first, blocks in order), the fallback path, the return value, and where to read more. What it delegates to the guide and to the 100%-covered schema is reasonable, though the guide reference means the description alone is not fully self-contained.

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 is 3, but the description adds genuine cross-parameter semantics the schema cannot: `story` is written before `blocks`, `blocks` elements must narrate the story in order, lines are 2-4 words per language, the end card is brand name slamming into `merge_into`, and `on_drop` belongs to exactly one block. That is more than the schema conveys field-by-field.

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 ('Creates a cinematic, music-synced launch video for an app or web product') and immediately enumerates the three concrete output shapes (9:16 Reel, 16:9 film, short teaser). It explicitly names the sibling tools it is not (create_project, update_launch_video), so an agent can route without opening another schema.

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 when to use it ('whenever the user wants a launch video, Reel or teaser') and when not to, with named alternatives: create_project for stills/App Store sets/animated film, update_launch_video for edits. It also prescribes the ordering of work ('Write the story first, then compose blocks in order') and points at the guide section to read first.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources