ClipFlux

Change a designed look

redraw_look

Changes a designed look that is not saved yet from a plain-words note ("warmer colours, thicker lines") and draws its 3 sample pictures again, shown in the ClipFlux card. Uses the same credits as designing one; call it only after the user asked for the change (the card's Redraw sends their note). The same rules as design_look apply to the note.

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": {
      "lookId": "<lookId>",
      "note": "<note>"
    },
    "name": "redraw_look"
  }
}

Input Schema

Name	Required	Description
`note`	Yes	What to change in the look, in plain words. Qualities only, no names.
`lookId`	Yes	The look id design_look returned ("own:...").
`channel`	No	The name of the user's ClipFlux channel the look is for, if it is for one. The card then offers to make it that channel's look.
`example_scene`	No	The same scene from the user's video as before, if the look had one.

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 8, 2026

TDQS

A3.9/5.0

Behavior4/5

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

Annotations only declare non-read-only/non-destructive/non-open-world; the description adds genuinely non-derivable behavior: credits are consumed at the same rate as designing, three sample images are regenerated, and the result surfaces in the ClipFlux card. Undisclosed: what happens if credits are insufficient and whether the prior samples are replaced or retained.

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 action and effect, then preconditions and cost. Slightly dense in the opening clause and mildly repetitive in "call it only after the user asked for the change (the card's Redraw sends their note)", but there is no filler.

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, so the description correctly covers the return surface (three redrawn sample images shown in the card) and the cost model. What remains thin is failure/edge behavior — insufficient credits, expired or already-saved lookId — for a tool with a non-trivial side effect.

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 schema already defines every parameter, including the note's "plain words, qualities only" rule and the lookId's "own:..." format. The description's inline example ("warmer colours, thicker lines") largely duplicates the schema, and its one addition — that design_look's note rules apply — is a pointer rather than new semantics.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a concrete verb and resource ("Changes a designed look") plus a real scoping constraint ("that is not saved yet") and the concrete effect ("draws its 3 sample pictures again"). It does not explicitly route against siblings like design_look or save_look by name for selection purposes, so it stops just short of a 5.

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?

Explicit trigger and precondition: "call it only after the user asked for the change (the card's Redraw sends their note)" — an agent knows not to invoke this proactively. It also notes the credit cost parity with design_look and defers note rules to design_look, though it never says what to use instead when the look is already saved (save_look/get_look territory).

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?