Skip to main content
Glama
Hermoso

Hermoso

Official

Upscale video

upscale_video

Upscale videos to 2x resolution for final delivery, choosing standard precision, FLUX detail enhancement, or detail rebuilding; returns the rendered URL.

Instructions

Upscale a video to higher resolution (2x) for final delivery. Paid render; returns the served URL. A 480p Seedance 2.5 draft: finish_draft (same take, native 1080p). Three engines: the default ('standard') is the safe precision upscaler; engine:'flux' is the FLUX 3 video upscaler (1080p/2K/4K) with an optional mode:'creative' detail-enhancement pass; engine:'detail' rebuilds fine detail such as hair, skin and fabric, the sharpest result for a hero shot and the most expensive. Pick 'flux' or 'detail' when the user asks for added detail rather than a faithful enlargement.

Input Schema

NameRequiredDescriptionDefault
modeNoFLUX only — 'creative' turns on its detail-enhancement pass; default precise
videoYesthe source video URL; a URL, not a local file path; use upload_file for local files
engineNodefault 'standard', the precision upscaler. 'flux' = the FLUX 3 video upscaler. 'detail' = rebuilds fine detail, costs the most

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.1.525
    • changedInput schema / properties / video / description
      Previous value: -"the source video URL"New value: +"the source video URL; a URL, not a local file path; use upload_file for local files"
  2. Changed2 schema fields changedv0.1.484
    • changedInput schema / properties / engine / description
      Previous value: -"default 'standard', the precision upscaler. 'flux' = the FLUX 3 video upscaler"New value: +"default 'standard', the precision upscaler. 'flux' = the FLUX 3 video upscaler. 'detail' = rebuilds fine detail, costs the most"
    • changedInput schema / properties / engine / enum
      Previous value: -[
      -  "standard",
      -  "flux"
      -]New value: +[
      +  "standard",
      +  "flux",
      +  "detail"
      +]
  3. Changed2 schema fields changedv0.1.256
    • changedInput schema / properties / engine / description
      Previous value: -"default topaz. 'flux' = the FLUX 3 video upscaler"New value: +"default 'standard', the precision upscaler. 'flux' = the FLUX 3 video upscaler"
    • changedInput schema / properties / engine / enum
      Previous value: -[
      -  "topaz",
      -  "flux"
      -]New value: +[
      +  "standard",
      +  "flux"
      +]
  4. Changed2 schema fields changedv0.1.249
    • addedInput schema / properties / engine
      Added value: +{
      +  "description": "default topaz. 'flux' = the FLUX 3 video upscaler",
      +  "enum": [
      +    "topaz",
      +    "flux"
      +  ],
      +  "type": "string"
      +}
    • addedInput schema / properties / mode
      Added value: +{
      +  "description": "FLUX only — 'creative' turns on its detail-enhancement pass; default precise",
      +  "enum": [
      +    "precise",
      +    "creative"
      +  ],
      +  "type": "string"
      +}
  5. 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
  6. Addedv0.1.0

TDQS

A4.5/5.0
Behavior4/5

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

Annotations already declare a non-read-only, non-idempotent, open-world mutation, so the description's job is to add cost and outcome context — which it does via 'Paid render; returns the served URL' and the relative expense of the 'detail' engine. It stops short of saying whether the call blocks or returns a job to poll via get_job, which matters for a paid render.

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 purpose, price signal and return value come first, with alternatives and engine choice following. Slight redundancy with the schema's own engine and mode descriptions, and the Seedance/finish_draft aside is compressed to near-cryptic, but nothing is padding.

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 3-parameter paid render with no output schema, the description covers purpose, cost, return URL and engine trade-offs. The gap is how the 'flux' engine's '1080p/2K/4K' output tiers are chosen, since no parameter exposes a target resolution, and there is no note on sync vs. async execution.

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 100%, so the enum values are already documented; the description earns credit by adding the decision rule behind them (default = precise upscaler, 'detail' = sharpest and most expensive, 'flux'/'detail' only when detail enhancement is requested) rather than restating the enums.

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 and resource plus the actual effect ('Upscale a video to higher resolution (2x) for final delivery') and the return value. It is clearly separable from neighbours like restyle_video, clone_video, finish_video and edit_video, which do different things to the same asset.

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 routes away from this tool for low-res Seedance drafts ('finish_draft (same take, native 1080p)') and gives a selection rule across the three engines: default for faithful enlargement, 'flux'/'detail' when the user wants added detail. Both the when-not and the alternative are named.

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