Skip to main content
Glama
hermoso-ai

Hermoso

Official
by hermoso-ai
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Remote

New opening hooks for a video

hook_variants

Generate multiple A/B test versions of a finished video ad by swapping in new opening hooks, keeping the rest of the footage and original soundtrack.

Instructions

HOOK MULTIPLIER: give ONE finished video ad N NEW OPENING HOOKS, N complete versions to A/B test. A planned hook replaces the first ~1.5-4 s (ends at the source's first cut there, else 3 s; hookSeconds overrides) with a new silent shot on a DIFFERENT named mechanic (list_hooks); the rest of the footage and the WHOLE original soundtrack stay, so every version keeps the source's length, and nobody in the hook talks or shows text. hooks[] adds your own openings: {url} a FOUND viral hook (post link or file) joined in front with the approved bridge (cut before its payoff, its own payoff sound carried across; post_edit price), {prompt} an opening described in words, {mechanic} a named one; with hooks and no count only those are made. To make the found hook's subject your product or creator first: recast_hook. Pass the video's FILE URL (a render, job result, list_library or upload_file). 1-5 versions, default 3. Refused free before billing: a source over 120 s, too short for a 1.5 s hook plus 2 s after it, unreadable, or a social post as the SOURCE (clone_video remakes someone else's ad). COST: a small planning read, then each planned version is billed like fix_beat for the hook's seconds; the reply quotes credits, and dryRun:true returns the plan and quote without rendering (pass that plan back to render exactly those). Returns ONE JOB PER VERSION; call get_job on each until done, never describe a version before its URL arrives. Hooks that show the product use the brand's product photo (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)
hooksNoyour own openings, one version each
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. Changed1 schema field changedv0.1.285
    • addedInput schema / properties / hooks
      Added value: +{
+  "description": "your own openings, one version each",
+  "items": {
+    "properties": {
+      "cutAt": {
+        "description": "url: override the found payoff cut",
+        "type": "number"
+      },
+      "mechanic": {
+        "type": "string"
+      },
+      "prompt": {
+        "type": "string"
+      },
+      "start": {
+        "description": "url: skip the video’s own first seconds",
+        "type": "number"
+      },
+      "url": {
+        "type": "string"
+      }
+    },
+    "type": "object"
+  },
+  "type": "array"
+}
  2. Addedv0.1.272

TDQS

A4.7/5.0
Behavior5/5

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

Annotations only state readOnlyHint=false/openWorldHint=true/idempotentHint=false/destructiveHint=false; the description carries far more: exactly what is replaced (first ~1.5-4 s up to the first cut), that footage and the whole soundtrack are preserved, that nobody talks or shows text, the billing model (small planning read + per-version like fix_beat), credit quoting, and the async contract (one job per version, poll get_job, never describe before the 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.

Conciseness3/5

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

Front-loaded with the core action, but it is a single dense paragraph of ALL-CAPS interjections and parenthetical caveats that is harder to scan than it needs to be. Every clause is substantive, yet the packaging and some redundant restatement (e.g. repeated note that the whole soundtrack/length is preserved) cost readability.

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?

Complete for a 10-param, no-output-schema mutation tool: it explains the async job flow in lieu of a return schema, the cost path, refusal guards, defaults, and the dryRun round-trip. Nothing an agent needs to call this 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 already 100%, so the baseline is 3, but the description adds real semantics: hookSeconds override behavior vs the default cut, resolution defaulting to the source's tier with a cost tradeoff, productImage/useBrand defaults, the {url}/{prompt}/{mechanic} entry meanings, and passing the dryRun `plan` back to render exactly those hooks.

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+resource and scope: 'give ONE finished video ad N NEW OPENING HOOKS, N complete versions to A/B test.' It explicitly distinguishes itself from siblings by naming list_hooks (mechanic source), recast_hook (changing the found hook's subject), clone_video (remaking someone else's ad), and fix_beat (billing analog).

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?

Explicit when-to-use conditions and alternatives: pass a file URL from render/job result/list_library/upload_file; use recast_hook first to swap the found hook's subject; clone_video is the route for a social post source. It also enumerates refusal conditions (over 120 s, too short, unreadable, social post as source) and when to choose dryRun.

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