Skip to main content
Glama
Hermoso

Hermoso

Official

Reframe video

reframe_video

Change a video's aspect ratio by preserving the full original frame and generating a new canvas around it while keeping audio and timing unchanged; returns the rendered video URL.

Instructions

Reframe a video to a different aspect ratio (e.g. 16:9 master -> 9:16 vertical): the whole original frame is kept and the new canvas around it is generated, with the sound and timing unchanged. Clips up to 300 seconds. Paid render; returns the served URL of the reframed video. Every placement at once (a free blur-pad by default): repurpose_video. A presenter on any video: add_presenter.

Input Schema

NameRequiredDescriptionDefault
videoYesthe source video URL; a URL, not a local file path; use upload_file for local files
aspectRatioYesthe target aspect ratio

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. 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.6/5.0
Behavior4/5

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

Annotations already declare readOnly=false, destructive=false, openWorld=true, idempotent=false, so the safety profile is covered. The description adds material behavior beyond that: a paid render, a 300-second input limit, and that audio/timing are preserved. It stops short of describing render latency, failure modes, or credit cost magnitude, which keeps it off a 5.

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-loaded with the core verb and mechanism, then constraints, then sibling routing – a sensible information order with no filler. The closing two clauses are compressed to the point of terseness ('Every placement at once (a free blur-pad by default): repurpose_video'), which costs a little readability.

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 2-parameter render tool with no output schema, the description covers what matters: input constraints, that output is a served URL, that sound/timing are preserved, that the call is paid, and which sibling to use instead. Nothing needed to invoke it correctly is missing.

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% with only two parameters, so the baseline is 3. The description still adds value by tying the 300s cap to the `video` input and illustrating the `aspectRatio` change concretely (16:9 -> 9:16), beyond the enum list the schema already 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?

Specific verb+resource ('Reframe a video to a different aspect ratio') with an explicit concrete example (16:9 master -> 9:16 vertical) and a description of the mechanism (original frame kept, new canvas generated). It clearly separates this from repurpose_video and add_presenter by naming both siblings.

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?

Routes the agent to the right sibling with conditions attached: style/asset-related alternatives are distinguished, with repurpose_video named for 'every placement at once (a free blur-pad by default)' and add_presenter named for videos containing a presenter. It also bounds applicability with 'Clips up to 300 seconds', so the agent knows when this tool is not suitable.

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