Skip to main content
Glama

Change a video that's already made (free preview)

preview_video_edit

Use this whenever the user wants to change a video they already have ("same words but more serious", "change line 3", "a stronger hook", "slower voice", "other colors", "no music", "shorter"): never make a new video from an idea for that. HypeFox starts from that video and changes only what the request touches: the other lines stay word for word, with the same scenes, voice, look and music. Free, about 15 seconds; it costs no credits. Returns the new lines (changed ones marked), what else changes and a script_id: show it to the user, change what they want, then make_video with that script_id and the final lines (edits are free: they cost no credits; the original video stays). Also videos made on the user's own footage, for 30 days (can_be_edited in get_video): there the voice is theirs, so the edit fixes how the captions are written, changes the on-screen texts (titles above the person, texts of the pictures), cuts lines, makes the ending longer ("the end cuts a word"), changes colors and music; the lines are the captions, all of them, and cut_lines / on_screen_texts / longer_ending say the rest. Not on videos made on the user's audio. What the user added in the app's editor (texts, stickers and photos on top, transitions, the subtitles' look) stays in the new video; adding those isn't done here: the user does it in the editor of the app. Waits up to 25 seconds; if it isn't ready yet, call get_script.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "video_id": "<video_id>",
      "request": "<request>"
    },
    "name": "preview_video_edit"
  }
}

Input Schema

NameRequiredDescriptionDefault
requestYesWhat to change, in the user's own words
video_idYesThe ready video to change (from list_videos or the context)

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.7/5.0
Behavior5/5

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

Annotations only declare it is not read-only, not destructive, not idempotent; the description adds far more: it is free and credit-free, takes about 15 seconds, preserves untouched lines, scenes, voice, look and music, preserves the user's own editor additions, and leaves the original video intact. It also states the 25-second wait and the get_script fallback — behavior no annotation conveys.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The critical rule is front-loaded, which is good, but the body is a dense run-on paragraph of parentheticals and quoted examples with some redundancy ('Free, about 15 seconds; it costs no credits' repeated as 'edits are free: they cost no credits'). It is informative but would scan far faster split into eligibility / behavior / next-step blocks.

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?

With no output schema, the description carries the return contract itself — new lines with changes marked, what else changes, and a script_id — plus the handoff flow to make_video/get_script. For a stateful, free-preview mutation with eligibility rules, that is sufficient to call and use it correctly.

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 baseline is 3, but the description adds real meaning: 'request' is framed as the user's own words with concrete edit categories (lines, hook, voice, colors, music, length), and 'video_id' is tied to a ready video sourced from list_videos or context. Minor deduction for referencing fields like cut_lines / on_screen_texts / longer_ending that are neither in the schema nor clearly labeled as returned values.

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 opening states a specific verb and resource — change a video the user already has — and immediately contrasts it with the sibling behavior it is not: 'never make a new video from an idea for that.' Real user-phrasings ('same words but more serious', 'change line 3') make the scope unmistakable.

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?

Explicit when-to-use ('whenever the user wants to change a video they already have'), explicit when-not (do not create a new video from an idea), explicit eligibility limits (30 days on the user's own footage, not on user's audio, can_be_edited from get_video), and explicit follow-ups (get_script on timeout, make_video with script_id after). Nothing is left to inference.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources