Skip to main content
Glama
hermoso-ai

Hermoso

Official
by hermoso-ai
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Remote

Stitch multi-scene video

stitch_video

Combine two or more video scenes into one continuous ad when a spot exceeds the chosen model’s single-clip limit; blocks until done and spends credits.

Instructions

Render a multi-scene STITCHED video (≥2 scenes) — ONLY for spots LONGER than ONE clip of the chosen model. A multi-beat ad that FITS one clip renders better and cheaper as ONE single-pass generate_video/render_ad (a single generation carries the whole hook->demo->payoff arc) — never stitch those. What fits is the model’s own maximum from hermoso_capabilities, not a fixed number: 15s on most models, 30s on the longest-clip one, so a 30s spot need not be stitched at all if you name that model. Blocks until done. Spends credits.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
modelNovideo model id from hermoso_capabilities — omit to let the router pick
voiceNovoiceover voice name, e.g. Rachel / George
scenesYesarray of scene objects (visual + optional voiceover/seconds)
voiceoverNofull voiceover script spoken across the scenes
resolutionNo720p (default), 1080p for full detail, or 480p for a cheaper draft
aspectRatioNooutput aspect ratio, e.g. 9:16 (default) / 1:1 / 16:9
durationSecondsNototal spot length in seconds (defaults to the sum of the scenes’ seconds)

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.1.251
    • changedInput schema / properties / resolution / description
      Previous value: -"1080p (default), or 480p/720p for a cheaper draft"New value: +"720p (default), 1080p for full detail, or 480p for a cheaper draft"
  2. Changed2 schema fields changedv0.1.161
    • changedInput schema / properties / resolution / description
      Previous value: -"720p (default), 480p draft, or 1080p final"New value: +"1080p (default), or 480p/720p for a cheaper draft"
    • 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
  3. Addedv0.1.15
  4. Removedv0.1.0
  5. First observedv0.1.0

TDQS

A4.3/5.0
Behavior4/5

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

Annotations disclose write/openWorld/non-idempotent, and the description adds two behaviors annotations cannot express: 'Blocks until done' (synchronous long-running call) and 'Spends credits' (cost). These materially affect invocation, though failure modes and partial-render behavior remain unstated.

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 governing rule (only stitch when longer than one clip) is front-loaded, with rationale following. It is dense and em-dash-heavy, leaning on caps-lock emphasis, but nearly every clause carries routing or cost information rather than filler.

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 non-read-only tool with no output schema, the description covers the decision logic, the blocking behavior, and the credit cost. It stops short of describing the returned result or how to inspect an in-progress render, so it is strong but not exhaustive.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so all 7 parameters are already documented in the schema; per the rubric the baseline is 3. The description reinforces a few (scenes ≥2, model from hermoso_capabilities, default duration as the sum of scene seconds) but adds little beyond what the schema already conveys.

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 ('Render a multi-scene STITCHED video') with the defining constraint (≥2 scenes), and names the sibling tools (generate_video/render_ad) it must not be confused with. An agent can distinguish it from its closest neighbors without opening either schema.

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 states when to use (spots longer than one clip of the chosen model), when not to use (any multi-beat ad that fits a single clip), and the alternative to pick instead. It even corrects the fixed-number assumption by pointing to hermoso_capabilities for the model's own max, so the routing decision is fully specified.

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