Skip to main content
Glama
Sign In

openFlow

by io.github.molkex
OverviewDiscussionsAdmin

recast_video

Re-make a video with YOUR character in place of the person in it: same camera, movement, gestures, timing and mouth movement, the character's look.

character: name from list_characters (its portrait is used as the look).
Source — ONE of media_id (a video this service made) or video_base64 (your own clip).
who: which person to replace when there are several ("the man on the left").
scene: one sentence about the room/background — helps keep it intact.
extra: anything else for the model ("keep the on-screen text").
start_sec/end_sec: recast only that piece (at most 10 s); the result is that piece.

Two steps:
  1. final=False (default) -> draft on abra_edit_360p, 10 credits: cheap check that
     the recast works on this clip (who gets replaced, does the scene hold).
  2. final=True -> 720p on abra_edit, 20 credits. NOTE: for edits the seed does NOT
     carry a take across resolutions (checked live 2026-10-15: the draft kept the
     person's hoodie, the 720p run replaced the whole body), so expect the final to
     differ in details from the draft. To repeat a FINAL take, reuse its seed with
     final=True.
Only for footage the user owns or is licensed to use; never put a real person's
likeness into a clip without their consent.

Input Schema

NameRequiredDescriptionDefault
whoNothe person in the video
seedNo
extraNo
finalNo
sceneNo
aspectNoVIDEO_ASPECT_RATIO_LANDSCAPE
end_secNo
media_idNo
characterYes
start_secNo
video_base64No
include_previewNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.5/5.0
Behavior5/5

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

Annotations only declare readOnly=false, idempotent=false, openWorld=true. The description adds substantial context beyond that: credit costs (10 vs 20), resolution differences (360p draft vs 720p final), the counterintuitive fact that seeds do not carry a take across resolutions, and the licensing/consent constraint. This is exactly the kind of behavior annotations cannot convey.

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?

Long but well-structured: labeled parameter explanations followed by a numbered two-step workflow, with the purpose front-loaded. Dense yet every section is relevant; minor redundancy between the parameter notes and the workflow narrative.

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 12-parameter, mutation-type, open-world tool with no output schema, the description covers source selection, character lookup, costs, resolution/seed behavior, and legal constraints. Only aspect and include_preview are left unexplained, which is a small gap for a tool of this complexity.

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 description coverage is 0%, so the description must carry all meaning, and it does for most parameters: character, media_id/video_base64 (as mutually exclusive sources), who, scene, extra, start_sec/end_sec (with the 10s cap), seed (repeat-a-final-take), and final. It leaves aspect (an enum) and include_preview undocumented, so not a full 5.

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 (re-make/recast) and resource (a video), then enumerates exactly what is preserved (camera, movement, gestures, timing, mouth movement) and what is swapped (the character's look). This clearly distinguishes it from siblings like edit_video and generate_video.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives strong operational guidance: source must be ONE of media_id or video_base64, character comes from list_characters, and it lays out a two-step draft-then-final workflow with the condition selecting each. No explicit routing against named sibling alternatives (e.g., edit_video), so it stops short of a 5.

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

All openFlow toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources