Skip to main content
Glama
Sign In
Hermoso

Hermoso

Official
by hermoso-ai
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Remote

New opening hooks for a video

hook_variants

Generate multiple opening hook variants for a finished video ad, producing complete versions to A/B test while keeping the original footage and 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: quoteOnly:true returns the exact credits free: state that first. A paid planning read (planCredits) runs next, then each planned version bills like fix_beat for the hook's seconds. dryRun:true pays for that read; pass its 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

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 = the paid plan and the price, no render
useBrandNofalse = send no brand name or product photo (for a video that is not this workspace brand’s)
quoteOnlyNotrue = the exact credits, free; nothing runs
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. Changed2 schema fields changedv0.1.489
    • changedInput schema / properties / dryRun / description
      Previous value: -"true = return the plan and the quote, render nothing"New value: +"true = the paid plan and the price, no render"
    • addedInput schema / properties / quoteOnly
      Added value: +{
+  "description": "true = the exact credits, free; nothing runs",
+  "type": "boolean"
+}
  2. Changed3 schema fields changedv0.1.465
    • addedInput schema / properties / hooks / items / properties / mechanic / description
      Added value: +"a named hook mechanic id from list_hooks"
    • addedInput schema / properties / hooks / items / properties / prompt / description
      Added value: +"an opening described in words"
    • addedInput schema / properties / hooks / items / properties / url / description
      Added value: +"viral hook to join in front: a post link or a video file"
  3. 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"
+}
  4. Addedv0.1.272

TDQS

A4.9/5.0
Behavior5/5

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

Adds substantial behavior beyond annotations: billing sequence, job-per-version flow, source constraints, soundtrack preservation, silent no-text hook rule, and get_job polling requirement. No contradiction with readOnlyHint=false, openWorldHint=true, idempotentHint=false, or destructiveHint=false.

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?

Front-loads purpose and mechanics effectively, and nearly every clause carries useful operational detail for a complex 11-parameter tool. However, it is very dense and run-on, with several concepts packed into long semicolon-linked sentences.

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 complex generation tool with no output schema: it explains cost modes, refusal conditions, plan handling, per-version job returns, and how to poll get_job before describing a version. An agent has enough information to invoke it correctly.

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?

Schema coverage is 100%, but the description adds operational meaning for key parameters: hooks[] url/prompt/mechanic behavior, count default, quoteOnly free pricing, dryRun paid planning, plan passback, hookSeconds override, resolution tier, and productImage/useBrand implications.

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 action and resource: give one finished video ad N new opening hooks, each a complete A/B-testable version. It distinguishes itself from nearby tools such as list_hooks, recast_hook, clone_video, and fix_beat by naming those alternatives in context.

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?

Explicitly covers when to use each mode: quoteOnly for free exact pricing, dryRun for paid planning, hooks[] for custom openings, and recast_hook when the found hook's subject must first become the product or creator. It also names refusal cases and the clone_video alternative for social-post sources.

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