Skip to main content
Glama
hermoso-ai

Hermoso

Official
by hermoso-ai
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Remote

Change narrator voice

change_voice

Swap a finished video's narrator voice while keeping the original performance, lip-sync, and background audio. Provide a video URL and voice preset to receive the served URL.

Instructions

Swap the narration of a finished video into a different voice — keeps the performance, lip-sync, and background sound. Use when the user likes the video but wants a different narrator voice; use dub_video only for language translation. Paid; returns the served URL.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
videoYesthe source video URL
voiceNotarget narrator voice preset name, e.g. 'Aria', 'George', 'Rachel', 'Sarah', 'Brian', 'Charlotte' (defaults to a warm female read). A saved VOICE CLONE of the user's own voice counts as a preset here — name it the way it is saved on their cast

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.1.209
    • changedInput schema / properties / voice / description
      Previous value: -"target narrator voice preset name, e.g. 'Aria', 'George', 'Rachel', 'Sarah', 'Brian', 'Charlotte' (defaults to a warm female read)"New value: +"target narrator voice preset name, e.g. 'Aria', 'George', 'Rachel', 'Sarah', 'Brian', 'Charlotte' (defaults to a warm female read). A saved VOICE CLONE of the user's own voice counts as a preset here — name it the way it is saved on their cast"
  2. 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
  3. First observedv0.1.0

TDQS

A4.4/5.0
Behavior4/5

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

Annotations cover the safety profile (not read-only, not destructive, not idempotent), and the description adds context beyond them: the operation is 'Paid,' it preserves 'the performance, lip-sync, and background sound,' and it 'returns the served URL.' This is meaningful behavioral disclosure consistent with the 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 sentences with zero waste: purpose, usage guidance, and cost/return detail. The core scoping constraint is front-loaded ahead of the alternative and cost notes.

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 2-parameter tool with full schema coverage and no output schema, the description covers purpose, selection criteria, cost, preservation guarantees, and return value. Only a minor gap: it does not state whether the tool is synchronous or produces a new render rather than mutating the original video.

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 the baseline is 3; both 'video' and 'voice' are already documented with examples and a default. The description adds no parameter-level detail beyond what the schema provides.

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?

The description opens with a specific verb and resource: 'Swap the narration of a finished video into a different voice.' It distinguishes itself from the closest sibling by stating 'use dub_video only for language translation,' so an agent can tell the two apart 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?

Gives an explicit trigger condition — 'Use when the user likes the video but wants a different narrator voice' — and names the alternative with its exclusive condition: 'use dub_video only for language translation.' Both when-to-use and when-not-to-use are stated with nothing left to inference.

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