MakersMCP

Overview Schema Source Related Servers Discussions Admin

Launch film from a website

make_launch_film

Generate a 20-40 second launch film from a product's own website, using its brand and page content, then render an MP4 with music and sound effects.

Instructions

Makes a 20 to 40 second launch film from a product's own site: it reads the brand and the page, plans the film (name and promise, the real screen in a browser window, the page's own headline, feature cards, a number the page states, the logo close) and renders film.mp4 with music and sound effects, all with Chrome and ffmpeg on this machine. Nothing is generated by AI: the film shows what the site says. film.json is the plan; edit it and call render_launch_film to render again. Rendering takes a few minutes. (launch-film 0.2.0, on this machine.)

Input Schema

Name	Required	Description
`sfx`	No	Set to false to leave out the sound effects.
`url`	Yes	The product's website, like https://linear.app
`jobs`	No	Clips rendered at once (default 2).
`keep`	No	Keep the work files, each clip's MP4.
`look`	No	The film's look (default: picked from the brand). launch_film_guide with topic looks says what each one suits.
`brand`	No	A brand kit you already have: an easybrandkit folder or its brand.json.
`music`	No	Set to false to leave out the music bed.
`words`	No	A words.json you already have, instead of reading the page again.
`aspect`	No	16:9 (default) or 9:16 for phones.
`out_dir`	No	Folder to save into, absolute or relative to /app. Default: launch-film-{host}.
`seconds`	No	Aim for this length (default 30).
`wait_seconds`	No	How long to wait for the result before returning a job_id to wait on. 45 is safe for clients that stop a tool call after 60 seconds.

Output Schema

Name	Required	Description
`kit`	Yes
`tool`	Yes
`files`	No
`folder`	No	Where the kit saved its files.
`job_id`	Yes
`passed`	No	For checks: whether the check passed.
`status`	Yes
`exit_code`	No
`last_line`	No	What the kit was doing last.
`next_action`	No
`elapsed_seconds`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Nov 5, 2026

TDQS

A4.3/5.0

Behavior5/5

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

Beyond the annotations (readOnly=false, openWorld=true, idempotent=false, destructive=false), the description discloses the runtime stack (Chrome and ffmpeg on this machine), the latency ('rendering takes a few minutes'), that output is a non-AI factual rendering of the site, and that film.json is an editable intermediate plan. That is materially useful behavior an agent cannot get from the annotation block.

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 with the outcome, then flows into mechanics, the film.json/render_launch_film follow-up, and latency. It is a single dense paragraph rather than a list, and the parenthetical build/version tag at the end is low-value, but no sentence is 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 12-parameter, long-running generative-ish job tool with an output schema, the description covers the artifact, its composition, the plan file, and expected runtime. It leaves the job_id/wait behavior to the wait_seconds schema entry, which is acceptable given coverage is complete and an output schema exists.

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

Parameters3/5

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

Schema description coverage is 100%, so every parameter (look, seconds, aspect, music, sfx, jobs, wait_seconds, brand, words) is already documented. The description adds only incidental context — the 20–40 second window and the musical/sfx layer — without explaining defaults or interactions between them; baseline 3 is appropriate when the schema carries the load.

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?

States a specific verb and artifact ('Makes a 20 to 40 second launch film from a product's own site') and enumerates what the film contains, so it is immediately distinguishable from render_launch_film (render only) and plan_launch_film (plan only). The scope — read the brand/page, plan, render film.mp4 — is concrete enough that an agent knows exactly what it produces.

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

Usage Guidelines4/5

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

It routes the agent to a sibling explicitly: 'film.json is the plan; edit it and call render_launch_film to render again,' and points at launch_film_guide (via the look param) for look selection. What is missing is a direct statement of when to choose make_launch_film over calling plan_launch_film first to review the plan, or when to use make_launch_stills instead.

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

Deploy Server