Skip to main content
Glama
hermoso-ai

Hermoso

Official

New opening hooks for a video

hook_variants

Create multiple A/B test versions of a finished video ad by swapping its opening seconds for a new visual hook, while keeping the original audio and all footage after the hook unchanged.

Instructions

HOOK MULTIPLIER: give ONE finished video ad N NEW OPENING HOOKS and get N complete edited versions to A/B test. WHAT CHANGES: a new opening shot over roughly the first 1.5-4 seconds (the hook ends at the source's first shot cut in that range, else at 3s; hookSeconds overrides). WHAT STAYS: everything after that point is the original footage, and the ENTIRE original soundtrack (voiceover, music, sound) plays under every version unchanged, so every version is the SAME length, aspect ratio and resolution as the source. Because the audio is kept, each hook is a VISUAL hook built to play under the words the source already says there: nobody in it talks to camera, it carries no on-screen text, and it does NOT write a new spoken hook line. Every version uses a DIFFERENT named hook mechanic chosen for the product (open mid-problem, before/after snap, object into frame, satisfying macro, pattern interrupt, POV, whip/snap-zoom, unexpected place, countdown to reveal); list_hooks describes them. Pass the video's file URL (a previous render, a job result, list_library, or upload_file for a local file). 1-5 versions, default 3. REFUSED FOR FREE, before anything is billed: a source over 120 seconds (trim it with post_edit first), one too short to leave 2 seconds of the original after a 1.5 second hook, an unreadable file, or a link to a social post rather than a video file (use clone_video to remake someone else's ad). COST: a small planning read, then each version is billed like fix_beat for the hook's seconds; the reply quotes credits per version, and dryRun:true returns the plan and the quote without rendering (pass that plan back to render exactly those hooks without planning again). Returns ONE JOB PER VERSION; call get_job on each until it reports done, and never describe a version before its URL arrives. Uses the workspace brand's product photo as a reference in hooks that show the product (productImage overrides; useBrand:false sends none).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
planNothe `plan` object a previous dryRun returned, to render exactly those hooks without planning again
countNohow many hook versions, 1-5 (default 3)
notesNoanything the hooks must respect, e.g. "keep it calm", "show the product in every hook"
videoYesthe finished video to give new hooks: its served file URL
dryRunNotrue = return the plan and the quote, render nothing
useBrandNofalse = send no brand name or product photo (for a video that is not this workspace brand’s)
resolutionNorender tier for the new opening. Defaults to the source’s OWN tier so the hook matches the rest of the ad; a lower tier costs a lot less and is scaled into the source’s canvas (visibly softer for the first seconds). dryRun quotes whichever you pick.
hookSecondsNowhere the CURRENT hook ends, in seconds (1.5-4). Omit to use the first shot cut.
productImageNoproduct photo URL used as a reference in hooks that show the product (defaults to the workspace brand’s first product photo)

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.1.272

TDQS

A4.9/5.0
Behavior5/5

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

Annotations are generic false flags, so the description carries the full behavioral burden, and it delivers: billing per version, one async job per version, a plan-vs-render distinction, refusal cases before charges, and explicit preservation of the original soundtrack and footage. It even warns not to describe a version before its job URL arrives.

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

Conciseness5/5

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

The description is long but appropriately sized for a 9-parameter tool with no output schema. Every labeled block—WHAT CHANGES, WHAT STAYS, REFUSED FOR FREE, COST—earns its place, and the core multiplier/audio-preservation constraint is front-loaded.

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 and only generic annotations, this description covers inputs, refusals, cost quoting, dryRun planning, job polling, and output expectations. Nothing essential to calling the tool correctly is missing.

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 real value on top for `video` by enumerating valid source forms (previous render, job result, list_library, upload_file) and for `hookSeconds` by explaining the fallback to 3s when no shot cut exists in range. Much of the other parameter detail, however, duplicates what is already in the schema, so it just misses a 5.

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 precise operation: take one finished video ad and produce N edited versions with new opening hooks over roughly the first 1.5-4 seconds. It clearly distinguishes itself from generic video editing tools by emphasizing that audio, length, aspect ratio, and resolution are preserved and only the visual opening changes.

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?

Provides explicit when-to-use and when-not-to-use conditions: source over 120 seconds should be trimmed with post_edit first, social post links should use clone_video, and list_hooks explains hook mechanics. It also spells out the dryRun/plan flow so an agent knows how to preview and quote before committing to renders.

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

Deploy Server

Other Tools