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

TDQS

A4.9/5.0
Behavior5/5

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

Annotations alone (readOnlyHint: false, destructiveHint: false) give little behavioral info for a creation tool. The description compensates richly: it discloses that the tool takes 'SEVERAL minutes', renders one image per frame with concurrent painting, requires 'the writing model and a narration voice engine connected', and details cost behavior (credit figures, frameDensity impact). It also explains the non-photoreal styling process and the caption/subtitle defaults. No contradiction with annotations; this is a complete behavioral disclosure.

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 given the tool's complexity (13 parameters, multiple enums, cost considerations, defaults), the length is largely justified. It is front-loaded with the core purpose and immediately names sibling alternatives. Each section is dense with useful information. I deduct one point because some sentences are redundant (e.g., repeated emphasis on captions being off by default) and the style list could be trimmed, but overall it is well-organized and informative without wasting words.

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 complex tool with no output schema, the description is exceptionally complete. It covers prerequisites, cost estimates, timing, defaults, edge cases (e.g., 'captions:true' implies 'subtitles:true'), and explicitly states what it is not for. It even details the rendering pipeline (stills with motion, not video model renders) to set expectations. An agent would have all the information needed to decide whether to call this tool and how to configure it properly.

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?

While schema coverage is 100%, the description adds substantial semantic value beyond the schema. For example, style is explained with a full list of visual families and their characteristics (e.g., 'storybook (gouache)'), captions/subtitles get deep behavioral explanation (defaults, timing, implications), and music gets cost and mood guidance. The description teaches the agent how to interpret and use parameters correctly, going far beyond simple name/type descriptions.

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 opens with a precise statement: 'Turn a TOPIC into a finished narrated explainer video.' It goes on to specify exactly what the tool does (writes script, paints pictures, narrates, composites end card) and explicitly distinguishes itself from siblings 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.' This gives both the verb+resource and clear sibling differentiation.

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 offers explicit usage guidance: it designates when to use this tool (explanations/teachings) and when not (short product ads, directing to alternatives). It also instructs the agent on how to behave, e.g., 'Ask the user which they want rather than picking silently' for style, and 'Never turn it on unasked' for upscaling and captions. It provides clear conditions for feature usage, including defaults and when to override them.

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.7/5.0
Disambiguation2/5

With 293 tools, the surface is enormous and many tools have overlapping purposes—multiple posting tools (post_to_meta, post_to_linkedin, schedule_post, etc.), multiple analytics tools per channel, and several search tools (search_meta_ads, search_instagram, search_reddit...). While each description is detailed, the volume makes it difficult for an agent to reliably distinguish between similar tools without careful reading, leading to frequent misselection.

Naming Consistency4/5

The naming is largely consistent with a verb_noun pattern (post_to_*, list_*, create_*, delete_*, update_*, manage_*). There are clear families for major operations. A few outliers like 'google_business_account', 'hermoso_capabilities', and 'store_get' break the pattern, but the overwhelming majority follow a predictable structure, making navigation somewhat easier.

Tool Count1/5

293 tools is far beyond any reasonable scope for a single MCP server, even for a comprehensive marketing platform. The calibration guide flags 50+ as an extreme mismatch, and this is nearly six times that threshold. Such a large surface overwhelms context windows, increases the probability of misselection, and makes it impractical for agents to learn or use effectively.

Completeness4/5

The tool set covers a vast domain: ad creation and rendering, posting across nine+ social channels, analytics and reporting, file management (Drive/OneDrive), competitor research, brand management, and more. It appears to provide CRUD and lifecycle coverage for most resources. While there may be minor gaps given the immense scope, the overall coverage is impressively comprehensive.