ClipFlux

Design a look

design_look

If you have not yet in this chat, call get_started first. Designs a look of the user's own from the fields you fill in: ClipFlux checks it, writes it the way its own looks are written, and draws 3 sample pictures (a person, a place or the user's own scene, an object), shown in the ClipFlux card with Save and Redraw buttons. Uses credits: call quote_look with the same fields first, and this only after the user has said yes to that price. Never name an artist, studio, franchise, brand, game or real person; ClipFlux refuses those for free and says why.

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": {
      "name": "<name>",
      "format": "<format>",
      "medium": "<medium>"
    },
    "name": "design_look"
  }
}

Input Schema

Name	Required	Description
`name`	Yes	The look's short name, 2 to 40 characters, for example "Chalkboard lessons". No artist, studio or brand names.
`avoid`	No	What must never appear in this look, for example "no glossy 3D, no neon".
`format`	Yes	The videos it is for: "short" draws the samples 9:16, "long" 16:9.
`medium`	Yes	What it is made with and how it is rendered, for example "chalk drawings on a dark green school blackboard" or "thick oil paint on canvas".
`people`	No	How people and characters are drawn (proportions, faces, detail), never who.
`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.
`palette`	No	The colours, for example "white chalk with yellow and pale blue accents".
`lighting`	No	The light, for example "soft classroom daylight".
`example_scene`	No	One scene from the user's video, so one sample shows their own content, for example "the Titanic sinking at night".
`lines_and_texture`	No	Lines, strokes and surface, for example "dusty chalk strokes, smudges".
`camera_and_framing`	No	Camera and framing, for example "flat front-on views, wide shots".

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 8, 2026

TDQS

A4.5/5.0

Behavior5/5

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

Annotations only say it is a non-read-only, non-destructive, closed-world call; the description adds the material facts an agent needs: it consumes credits, it performs a content-policy check (no artist, studio, franchise, brand, game or real person) and refuses those for free with an explanation, and it produces 3 samples presented with Save and Redraw buttons. That is substantial context beyond the annotations.

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?

Four dense sentences, all of which earn their place, though the prerequisite sentence is front-loaded ahead of the purpose statement, which delays the core 'what it does' line. The content-policy sentence is slightly long but carries real constraint information.

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 an 11-parameter, credit-consuming generation tool with no output schema, the description covers prerequisites, cost gating, policy refusal, and what the user sees (3 samples in a card with Save/Redraw). Minor gaps remain: it does not state whether the look is persisted or what identifier is returned, though the Save button wording implies it is not auto-saved.

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 description coverage is 100% and every one of the 11 fields has an example and constraint, so the schema carries the parameter meaning. The description only adds that the same fields must be reused for quote_look, without explaining field-level semantics such as how name/medium/avoid interact. Baseline 3 is appropriate.

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 and resource ("Designs a look of the user's own") and immediately describes the concrete outcome: ClipFlux checks it, rewrites it in its own style, and draws 3 sample pictures (person, place/own scene, object) shown in a card. This clearly separates it from siblings like save_look, redraw_look, get_look and quote_look.

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 ordering and gating rules: call get_started first if not already done in this chat, call quote_look with the same fields, and only proceed after the user has said yes to that price. It also names the alternative to run first, so the agent knows exactly when to use this versus quote_look.

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?