ClipFlux

Price a new look

quote_look

Read-only

If you have not yet in this chat, call get_started first. Shows the ClipFlux card with a look of the user's own as you would design it (the fields you fill in, from what you know about the user, the channel and the video) and its price: writing it and drawing 3 sample pictures (a redraw costs the same). Creates nothing and spends nothing. Describe qualities only: never an artist, studio, franchise, brand, game or real person. Then wait: call design_look with the same fields only after the user says yes (the card's button sends "Yes, design the look.").

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": "quote_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.
`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 already declare readOnly/non-destructive/closed-world, and the description reinforces that with 'Creates nothing and spends nothing' while adding information annotations cannot carry: the pricing model (write + 3 samples, redraw same price) and a hard content constraint (describe qualities only, never an artist, studio, franchise, brand, game or real person). It also discloses the required human-in-the-loop pause before design_look.

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-loads the prerequisite and the core action, then the constraint and the wait-for-confirmation rule; nearly every sentence carries distinct information. Slightly dense with stacked parentheticals ('the card's button sends "Yes, design the look."'), but nothing is redundant.

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 still explains what the agent gets back (the card with the filled-in fields and a price covering writing plus 3 sample images) and what happens on a redraw. Combined with the workflow gate before design_look, an agent has everything needed to call 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 the baseline is 3, but the description adds real meaning: the fields should be filled from what is known about the user, the channel and the video, and the qualities-only rule constrains values in name/medium/people. It also tells the agent the same field set is reused for design_look, which the schema alone does not.

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 action: shows a preview card of the look as it would be designed, plus its price for writing and 3 sample images. The sibling differentiation is implicit but strong ('Creates nothing and spends nothing' vs design_look which does). The phrasing 'a look of the user's own as you would design it' is slightly convoluted, which keeps it off 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 Guidelines5/5

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

Gives explicit prerequisites (call get_started first if not yet in this chat), an explicit hand-off (call design_look with the same fields only after the user says yes, and names the exact button text that constitutes yes), and a cost note that a redraw costs the same. There is no ambiguity about when to call this versus the alternatives.

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?