Skip to main content
Glama

Make an explainer video

make_explainer

Turn a TOPIC into a finished narrated explainer video. Writes a sectioned script, paints a BURST of pictures per section (about one every 1.5s — most of them one-detail edits of the frame before, so it reads as movement rather than a slideshow), narrates each section with TTS, holds each picture PERFECTLY STILL for its own slice of the narration (the motion is the CUT RATE — a slow move on a still shimmers), then composites the end card (and any on-screen text you asked for) with the Chrome+ffmpeg engine the ads use (text is never model-painted, so it never garbles). BURNED ON-SCREEN TEXT IS OFF BY DEFAULT — the narration carries the point and the pictures carry the story, so the film ships clean unless the user asks otherwise; captions:true adds held key points and subtitles:true adds narration-timed CAPS (see both). It is an image film WITH motion, not N video-model renders — that's what keeps it affordable. style picks the visual family: the default 'cinematic' is photoreal editorial; every other id is a STYLED, strictly non-photoreal look (illustrated / collage / clay / pixel …) that first renders ONE style-key image and then locks every scene to it, so the whole film holds one look. Cost at the default frame density: a ~130-credit hold for a 60s explainer on the default style, ~100 styled; frameDensity:'lean' roughly halves it and 'minimal' (one picture per section) is ~30. All settle to the exact per-frame image + narration spend (a longer target = more sections = more). Takes SEVERAL minutes — one image render per frame; independent frames are painted concurrently, so it is far faster than the frame count suggests. Needs the writing model and a narration voice engine connected. NOT the tool for a short product ad — use render_ad or generate_video for those, and make_template_ad for the deterministic native formats.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
musicNomusic bed under the narration, measured to sit about 14 dB under the voice and sidechain-ducked beneath it. Omit and the KIDS and FAIRYTALE channels get their recommended bed COMPOSED for this film — those two are the only channels a bed is due on unasked, and it costs a small flat fee; every other channel ships dry. 'off' forces silence. 'library' takes a free curated track only, and ships dry when none is on file. NAME A MOOD — upbeat / calm / warm / epic / tense / playful / elegant / hype / chill / dramatic — to compose one on ANY channel, at the same fee. hermoso_capabilities reports the exact figure as explainerMusicCredits; quote it before you turn a bed on or pick a mood.
styleNovisual style. 'cinematic' (default) is photoreal; the rest are non-photoreal styled looks — editorial_collage (halftone cutouts + marker accents), flat_vector, stickman, whiteboard, ink_marker, silhouette, storybook (gouache), paper_diorama, isometric, claymation, pixel_art, watercolor, fluffy_toy (felted plush), low_poly, stylized_3d (matte clay render), studio_3d (preschool toy 3D on a white sweep — the Kids default), mannequin (clay-render reenactment figures — a History alternate). Ask the user which they want rather than picking silently; a styled pick costs more (see the cost note).
topicYeswhat the explainer should teach or explain — a topic or a short brief
voiceNonarration voice name — omit for the default warm read
channelNothe CHANNEL TYPE — it sets the pacing, the narration register and the default look, and is orthogonal to `style` (a named style always wins): explainer (casual second-person, fast cuts), history (witty chronological retelling / documentary), kids (fastest, question-first, warm teacher), fairytale (slow, atmospheric myth or folklore). Default 'explainer'.
endCardNoappend the branded end card (default true)
upscaleNooptional FINAL upscale — 2 doubles each side, 4 quadruples. Captions and the end card are burned BEFORE it so they upscale with the frame. It is priced BY LENGTH and it is the expensive part — several times the cost of rendering the film itself. hermoso_capabilities reports the exact figures per length as explainerUpscaleCredits. Never turn it on unasked: quote the number and let the user choose.
captionsNoturn ON-SCREEN TEXT on. DEFAULT FALSE, and leave it false unless the user asks — the narration already says the point and the pictures carry it, so the clean film is the better default. `captions:true` on its own burns SUBTITLES (see below), because that is what a caption is for: showing what is being said when the phone is on mute. Slim white CAPS, thin black outline, bottom safe band, no plate, no box.
brandNameNobrand name for the end card — omit to leave it unbranded
subtitlesNowhich on-screen text, once `captions` is on. LEAVE IT UNSET (or true) for SUBTITLES — every spoken word, in order, timed to the narration; free, no extra render, no extra credits, and there is NO cue limit, so the whole film is subtitled however long it runs (at most 5 words / 32 characters a line). Set it FALSE only if the user explicitly wants section HEADINGS instead: one short summary label held over each ~7-15s section. That is NOT what is being said — it is a label about it — so it is the wrong answer to "add captions" and to anyone watching on mute. `subtitles:true` also implies `captions:true`. TIMING: each cue is anchored to that section’s REAL measured narration length and distributed inside the section by character count — exact at every section boundary, approximate to a few tenths of a second within one. It is not a word-level speech clock, so never promise frame-accurate sync.
aspectRatioNo'9:16' default
frameDensityNohow many pictures per second of narration, and therefore what it costs. 'standard' (default) is a frame about every 1.5s — the density a stills film needs to read as a film rather than a slideshow; 'lean' is one about every 2.5s (the longest hold that still reads as a film, ~40% of the frames and ~40% of the cost); 'minimal' is ONE picture per narration section, which is cheapest and is frankly a slideshow. Only drop below the default if the user asked for something cheaper.
durationSecondsNotarget length 20-120s (default 60); drives the section count — ~10s of narration each, 3-8 sections

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. First observed

TDQS

A4.9/5.0
Behavior5/5

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

While annotations are minimal (readOnlyHint: false, etc.), the description is exceptionally transparent about behavior. It discloses that the tool takes "SEVERAL minutes — one image render per frame; independent frames are painted concurrently, so it is far faster than the frame count suggests." It explains the internal motion mechanism ("the motion is the CUT RATE — a slow move on a still shimmers"), the compositing engine ("Chrome+ffmpeg engine the ads use"), text rendering ("text is never model-painted, so it never garbles"), the styled-look locking behavior, cost implications, and the fact that it needs "the writing model and a narration voice engine connected." It also reveals the default off behavior for burned text. This far exceeds what annotations provide.

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?

The description is long but every sentence earns its place; it covers a high-complexity tool with 13 parameters. It front-loads the core behavior in the first clause and then layers details. The occasional use of CAPS and dash-separated asides helps skimming. It is dense but not bloated; a slight deduction because some sections (e.g. captions/subtitles) are verbose and could be tightened, but overall it is well-structured for an AI agent's decision-making.

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?

Given the 13-parameter complexity and the rich input schema, the description is remarkably complete. It covers costs, engine used, runtime expectations, concurrency, prerequisite connections, defaults, user-consent expectations, and explicit non-use cases. There is no output schema, but the description compensates by describing the finished output (narrated explainer video with script, pictures, TTS, end card) and cost reporting via hermoso_capabilities. An agent has everything needed to select, invoke, and appropriately set parameters.

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

Parameters5/5

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

The input schema covers 100% of parameters, so the baseline is 3. The description adds substantial meaning: for each parameter, it gives context on its behavioral effects, defaults, costs, and when to use it. For example, `frameDensity` is explained in terms of visual film-reading quality, cost percentages, and default behavior. `captions` and `subtitles` are distinguished with default rules and user expectations. `music` gets a detailed explanation of sidechain ducking, channel-specific defaults, cost reporting via hermoso_capabilities, and mood-based composition. `upscale` is heavily contextualized with cost warnings. `style` explains the photoreal vs. non-photoreal split, style-key locking, and the cost note. This adds meaning far beyond the schema.

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?

The description is explicit and specific: "Turn a TOPIC into a finished narrated explainer video." It clearly differentiates this from siblings like render_ad, generate_video, and make_template_ad by stating "NOT the tool for a short product ad — use render_ad or generate_video for those, and make_template_ad for the deterministic native formats." It names the resource (topic), the action (make), and the unique output characteristics.

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?

The description explicitly states when to use this tool versus alternatives: "NOT the tool for a short product ad — use render_ad or generate_video for those, and make_template_ad for the deterministic native formats." It also provides clear guidance on when to use parameters like captions, subtitles, style, frameDensity, and upscale — e.g., "Never turn it on unasked: quote the number and let the user choose." This is exemplary usage guidance.

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.

TDQS

A3.8/5.0
Disambiguation3/5

The descriptions are exceptionally detailed and cross-reference one another (e.g. post_edit vs finish_video vs edit_video), which genuinely helps, but 168 tools still contain tight clusters—video creation/editing, scheduling, and post-publishing—where misselection is easy. Many tools also reference hidden companions not in the visible set, adding ambiguity.

Naming Consistency4/5

The overwhelming majority follow a clear verb_noun snake_case convention (post_to_x, search_x, list_x, create_x, update_x). Minor deviations like store_get, billing_status, error_detail, and the hermoso_ prefix break the pattern slightly but do not obscure it.

Tool Count1/5

At 168 tools this is far beyond the 50+ threshold, and regardless of how broad the platform's purpose is, the sheer number makes the set hard to navigate. The server mitigates with groups and find_tools/call_tool, but the count itself is extreme.

Completeness4/5

The set covers a full marketing lifecycle—research, planning, creation, publishing, scheduling, measurement, billing, and file management—with no major workflow gaps. Some referenced tools like list_shopify_products and manage_meta_post are not in the visible list, but find_tools and call_tool are explicitly designed to close that gap.