ClipFlux

Price a video

quote_video

Read-only

If you have not yet in this chat, call get_started first. Says how many ClipFlux credits a video would use before anything is made (the amount held while it is made; any unused part goes back), the user's available credits, and whether the account has a free preview. Creates nothing and spends nothing. Only for when the user asks what a video would cost before there is a draft: draft_video's card already shows the price on its Make button.

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

Input Schema

Name	Required	Description
`look`	No	The look id the user picked (a ClipFlux look, or "own:..." for one of their own), shown on the card.
`title`	No	The video's short title, shown on the card.
`voice`	No	The narrator id the user picked, shown on the card.
`format`	Yes	"long" for a 16:9 YouTube video in chapters, "short" for a vertical Short.
`pacing`	No	Long videos only: "standard" (one picture a sentence) or "fast" (a new picture every few seconds, costs more).
`script`	No	The script you wrote with the user. Always send it when there is one: the price follows its length (a long video takes its minutes from it), and a script past the account's limits is refused here, before anything starts.
`minutes`	No	Long videos ClipFlux writes: the length in minutes. Default 10. Leave it out with a script: the script sets the length.

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 8, 2026

TDQS

A4.6/5.0

Behavior4/5

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

The annotations already declare readOnlyHint=true and destructiveHint=false, and the description is consistent with them ('Creates nothing and spends nothing'). Beyond that it discloses genuinely non-obvious behavior: the quoted amount is held during creation with the unused part returned, an over-limit script is refused at quote time rather than at make time, and free-preview status is reported. It does not describe output shape, but no output schema exists and the returned fields are named in the description, so the gap is small.

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, then the purpose, then the exclusion, which is the right order for an agent scanning for routing signals. The parenthetical about held credits is dense but pays for itself; a small amount of nesting makes it read busier than it needs to be.

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?

For a 7-parameter read-only pricing tool with no output schema, the description covers what is computed, what is returned, what is not done (no creation, no spend), the prerequisite tool, and the sibling that makes it redundant. An agent has everything needed to decide whether and how to call it.

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, and the description earns above that by adding a real usage rule for 'script' (always send it when one exists, because price follows its length and over-limit scripts fail here) and by clarifying that 'minutes' should be omitted when a script is supplied. The remaining parameters are left entirely to the schema, which already describes them well.

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 (prices how many credits a video would use) plus the three pieces of information returned: credit cost, available credits, and free-preview eligibility. It explicitly separates itself from get_credits (account balance) and draft_video (which shows price on its Make button), so an agent can route correctly without opening another schema.

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 an explicit when: the user asks what a video would cost before a draft exists. Gives an explicit when-not: draft_video's card already shows the price, so quoting again is redundant. It also states the get_started prerequisite, which is a hard sequencing rule an agent would otherwise miss.

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?