ClipFlux

Redo a scene

redo_scene

Destructive

Redoes one scene of a video whose pictures are made: either draws its picture again from a plain-words note of what to change, or records its narration again with new words. Uses a few credits for that scene; the result says how many. Only for a change the user asked for in their own message: never to apply a rewrite or improvement you suggested yourself unless the user said yes to it, and showing, exporting or posting a video is not a request to change it.

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": {
      "videoId": "<videoId>",
      "scene": "<scene>"
    },
    "name": "redo_scene"
  }
}

Input Schema

Name	Required	Description
`line`	No	New words for the narrator to say in this scene.
`note`	No	What to change in the picture, for example "make it night" or "no face in the window yet".
`scene`	Yes	The scene number, as get_video lists them.
`videoId`	Yes	The video id, from draft_video, list_my_videos or get_video.

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 8, 2026

TDQS

A4.3/5.0

Behavior4/5

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

With destructiveHint=true already declared, the description still adds value: it discloses that the call consumes credits per scene and that the response reports the count, which annotations cannot convey. It implies replacement of the existing picture or narration but never states whether the previous version is recoverable, leaving part of the destructive behavior implicit.

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 action and its two modes, then the cost, then the guardrails. The final sentence is long but every clause carries a distinct prohibition that prevents misfires, so little could be cut without losing safety guidance.

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?

No output schema exists, and the description compensates by noting the result reports credit usage. For a credit-consuming, destructive rewrite tool the essentials are covered; the main unresolved detail is what happens if both line and note are supplied, or if neither is.

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 coverage is 100%, so the baseline is 3. The description does add real meaning by framing the two parameters as an either/or mode choice (note = change the picture, line = new narration), which the schema's flat optional properties cannot express on their own, but it adds no format or length guidance beyond the schema.

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 (redoes) on a specific resource (one scene of a video whose pictures are made) and enumerates the two distinct modes: redrawing the picture from a plain-words note, or re-recording narration with new words. This is clearly separable from draft_video, edit_video, and redraw_look, which operate on whole videos or looks.

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 explicit when-not conditions: only for a change the user asked for in their own message, never to apply an agent-suggested rewrite unless the user approved it, and viewing/exporting/posting is not itself a change request. It also states a precondition (the video's pictures must already be made). The only gap is that it does not name a sibling tool by name as the alternative.

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

All ClipFlux tools Inspect

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

Need Help?