Skip to main content
Glama
hermoso-ai

Hermoso

Official
by hermoso-ai
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Remote

Fix a video beat

fix_beat

Fix a broken shot by re-rendering only the 1.5-8 second window and splicing it back onto the original video track, leaving audio and the rest byte-identical. Use when one beat glitches and a full re-render would waste working footage.

Instructions

Surgically re-render ONE time window (1.5-8s) of an existing rendered video and splice it back on the VIDEO TRACK ONLY — the rest of the video and ALL audio stay byte-identical. Use when one beat/shot is broken ('the shot at 8 seconds glitches') and a full re-render would waste the parts that worked; bills only the replacement clip's seconds (~1/3 of a full render). Do NOT pick a window covering spoken dialogue (a video-only splice under speech breaks lip-sync) — pass speechWindows to enforce this.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
promptYeswhat the replacement footage should show — describe the shot, matching the master's style
refImageNooptional product/style anchor image URL
videoUrlYesthe served URL of the master video to fix
endSecondsYeswindow end in seconds (window 1.5-8s)
startSecondsYeswindow start in seconds
speechWindowsNo[[start,end],...] windows with spoken lines — the fix window must not overlap these

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.1.161
    • changedOutput schema / (root)
      Previous value: -{
-  "$schema": "http://json-schema.org/draft-07/schema#",
-  "additionalProperties": false,
-  "properties": {
-    "jobId": {
-      "description": "the render job id — poll get_job with this id to resume or inspect",
-      "type": "string"
-    },
-    "model": {
-      "anyOf": [
-        {
-          "type": "string"
-        },
-        {
-          "type": "null"
-        }
-      ],
-      "description": "the product-facing label of the model that rendered it"
-    },
-    "raw": {
-      "description": "the raw job result payload (e.g. images[] for carousel template ads)"
-    },
-    "stillRendering": {
-      "description": "true when the render is still in progress — keep polling get_job with jobId",
-      "type": "boolean"
-    },
-    "url": {
-      "anyOf": [
-        {
-          "type": "string"
-        },
-        {
-          "type": "null"
-        }
-      ],
-      "description": "the served URL of the finished media (absent/null while still rendering)"
-    }
-  },
-  "type": "object"
-}New value: +null
  2. Addedv0.1.0

TDQS

A4.9/5.0
Behavior5/5

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

Although annotations only tell us readOnlyHint=false, destructiveHint=false, idempotentHint=false, the description clearly discloses the surprising behavior: video track is replaced while the rest of the video and ALL audio stay byte-identical. It also surfaces the billing consequence ('bills only the replacement clip's seconds (~1/3 of a full render)') and the lip-sync hazard. No contradiction with annotations.

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?

Three dense sentences, each earning its place: behavior, when-to-use plus cost, and a critical do-not rule. The most important behavioral constraint is front-loaded ('VIDEO TRACK ONLY'), and the sibling-differentiating angle comes immediately. No filler.

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 surgical video-editing operation with no output schema, this description covers the key preconditions, constraints, side effects (audio preservation), billing model, and the one dangerous exclusion (speech overlap). The six parameters are all documented in the schema and the description maps them to behavioral context. Nothing critical is missing for an agent deciding to call it and pick a window.

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 description coverage is 100%, so a baseline of 3 applies. The description adds meaningful semantics beyond the schemas: it defines the window constraint (1.5-8s), the enforcement rule for speechWindows, and the billing implication of choosing a smaller window. It doesn't detail the exact format of refImage or prompt beyond 'what the replacement footage should show', but parameter semantics are largely carried by the schema.

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 ('surgically re-render ONE time window... and splice it back'), a specific resource (existing rendered video, VIDEO TRACK ONLY), and a precise scope. Differentiates itself from full re-render and from video siblings like clip_video or edit_video by describing the surgical splice behavior.

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 says when to use this tool ('when one beat/shot is broken... and a full re-render would waste the parts that worked'), what it bills, and gives a hard exclusion ('Do NOT pick a window covering spoken dialogue') with the mechanism to enforce it (pass speechWindows). This goes beyond any sibling definition.

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