Skip to main content
Glama

Hermoso

by io.github.hermoso-ai

Render ad video

render_ad

RECOMMENDED for finished video ADS: render a plan_ad concept through the SAME quality pipeline as the Hermoso web Studio — timed shot list, exact/clean speech (no garbled words), text composited in post (never model-painted), brand end card, licensed music bed, real product references. Pass plan_ad’s full structured output as creative. Honors the plan’s render_plan structure/duration: a storyboard that FITS ONE CLIP OF THE RENDER MODEL renders as a single continuous pass; anything longer automatically renders as STITCHED ACTS (the fewest balanced clips, each at most one model clip) — never time-compressed into one clip. That threshold is the render model’s own maximum, not a fixed number: most models cap a clip at 15s and the longest-clip one goes to 30s, so use dryRun:true to see the act split this plan will actually get, for free, before spending. CAST A SAVED CREATOR with creator so the SAME person stars in this ad as in the last one (list_creators is the roster) — otherwise every render invents a new face. Renders take 1–3 min; keep polling get_job if it returns still-rendering. Spends credits.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
modelNovideo model id from hermoso_capabilities (default: the plan’s pick). Naming one is a DELIBERATE pick — the server asks before ever swapping it (no silent fallback)
musicNolicensed music bed on/off (default on)
dryRunNoreturn the routing decision (single pass vs stitched acts, resolved model + act lengths) WITHOUT submitting a render — free, nothing charged
lockupNopersistent brand-logo lockup overlay on/off
creatorNoCAST A SAVED CREATOR in this ad — their id from list_creators, or the name you know them by (“Sarah”). Their saved portrait becomes the on-camera identity for the whole spot, so the same face carries across every act and across every ad you render for this brand — and because we already have their picture, the character portrait this pipeline would otherwise generate is skipped, so casting somebody costs LESS than not casting them. Omit to let the ad cast a fresh person. Refused for free, with nothing rendered, if the name matches nobody or more than one creator, if the plan has nobody on camera, or if they are a REAL person with no likeness consent on file.
endCardNobranded end card on/off (default: on, except organic recipes)
captionsNoburn the plan's per-scene on-screen words as caption pills. DEFAULT FALSE — leave it off unless the user asks for on-screen text (no captions, or true subtitles of what is said; never scene or emphasis labels); a recipe whose format IS on-screen text keeps its text either way
creativeYesthe FULL structured output of plan_ad (must contain video_storyboard)
ttsVoiceNovoiceover voice name (e.g. Rachel / George) when the plan voices over
resolutionNo'1080p' default (what we ship and bill for); '480p'/'720p' = cheaper draft passes, '4k' = premium final delivery (more credits). NOT EVERY MODEL OFFERS EVERY TIER — this enum is what the tool accepts, and each model's OWN `resolutions` list in hermoso_capabilities is what it can actually render (the longest-clip 30s model, for one, tops out at 720p). Ask for a tier the chosen model does not list and it is rendered at that model's best available tier instead, with nothing in the reply saying so — so check `resolutions` before promising anyone 1080p or 4k.
aspectRatioNooutput aspect ratio, e.g. 9:16 (default) / 1:1 / 16:9
durationSecondsNototal ad length in seconds (supported range 4–180; outside that it is clamped). Omit to honor the plan’s own duration — that is almost always right. This only RE-TIMES an already-authored board (its scenes are scaled to fit), it does NOT re-write it, so to change the length of the ad the user asked for, re-run plan_ad with durationSeconds instead. A length that fits ONE clip of the render model renders as one continuous pass; longer is stitched from acts filled to that model’s clip maximum with the remainder last — the maximum is 15s on most models and 30s on the longest-clip one, so use dryRun:true to see the exact act split for free before spending.
allowGenericProductNoproceed even though this brand has NO product photo on file and the ad features a product — the packaging will be INVENTED. Only pass true after telling the user that and hearing they are fine with a generic stand-in

Schema Changelog

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

  1. First observed

TDQS

A4.5/5.0
Behavior5/5

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

With all four annotations false, the description carries the full burden and delivers unusually well: it discloses 'Spends credits,' 1–3 min latency with get_job polling, automatic STITCHED ACTS routing, silent resolution fallback ('rendered at that model's best available tier instead, with nothing in the reply saying so'), and explicit creator-refusal conditions. None of this contradicts the annotations; readOnlyHint=false is consistent with a credit-spending mutation.

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 ~230-word body is dense with genuine information and front-loads the core purpose before behavioral detail; nearly every sentence earns its place. However, the heavy ALL-CAPS emphasis (RECOMMENDED, SAME, STITCHED ACTS, DELIBERATE) and stream-of-thought structure reduce scannability for an agent trying to extract key facts quickly.

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 13-parameter, credit-spending tool with no output schema, the description is remarkably complete on behavior: defaults, fallbacks, refusals, latency, routing, and cost are all covered. The main gap is the return payload of a submitted render — it implies a job via 'keep polling get_job if it returns still-rendering' but never states what render_ad itself returns.

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; the description adds workflow-level semantics the schema cannot, such as linking `creative` to plan_ad's output, `creator` to the list_creators roster, `dryRun` to a free act-split preview, and `resolution`/`model` to hermoso_capabilities. Since the schema already documents each parameter in exceptional detail, the incremental value is real but moderate.

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 resource — 'render a plan_ad concept through the SAME quality pipeline' — and opens with the routing signal 'RECOMMENDED for finished video ADS.' It distinguishes itself from plan_ad (which produces the creative input) and from generic video-generation siblings by requiring plan_ad's full structured output as `creative`.

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?

Gives clear context and chains the surrounding workflow: plan_ad produces `creative`, list_creators is the casting roster, hermoso_capabilities lists models/resolutions, and get_job is polled while rendering. It does not explicitly name sibling rendering alternatives (generate_video, make_template_ad, multiply_ad) or state when not to use them, so it falls short of a full when/when-not routing.

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

All Hermoso toolsInspect
Try in Browser
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

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.

Resources