Veltake Design

Break a video into shots

start_breakdown

Start a shot breakdown of a video clip. Always measures every cut, each shot's length and camera motion, and extracts two keyframes per shot — free. With label:true an AI model also reads every shot (shot size, camera move, what the shot is for, a description, text prompts to recreate it) and writes an overview, a summary and the clip's structure — that SPENDS the user's coins: pass expected_total exactly as estimate_breakdown priced it (the model's coins, plus transcribe_coins when transcribe:true). If the price changed, nothing is spent. Runs in the background: poll get_breakdown.

Input Schema

TableJSON Schema

Name	Required	Description
`lang`	No	the language the descriptions are written in — omit for English
`label`	No	true = add the AI read of every shot (costs coins); false or omitted = the free measured table
`title`	No	a name for the breakdown — omit to have one written from the read
`funding`	No	who pays: personal (the person's own coins) or team (their team's pool — only when the person allowed this connection to spend team coins and the team approved this app). Omit to use the payer the person chose when connecting
`purpose`	No	why the clip is being read — steers the descriptions and the summary: remake (default), pacing or ads
`video_url`	Yes	an https link straight to the video file, as passed to estimate_breakdown
`transcribe`	No	also transcribe the speech so the read can use it (needs label; costs transcribe_coins)
`label_model`	No	a model id from estimate_breakdown's label_models — omit for the default
`prompt_lang`	No	the language the recreate prompts are written in — omit for lang
`expected_total`	No	required with label:true — the total coins estimate_breakdown quoted for this choice
`idempotency_key`	No	optional: repeat it on a retry so the retry answers the first breakdown instead of charging again

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 19, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Annotations only declare readOnlyHint=false, destructiveHint=false, openWorldHint=true. The description goes well beyond: it discloses that the paid path SPENDS the user's coins, that expected_total must match the estimate or nothing is spent, that the job runs in the background, and that idempotency prevents a double charge. This is exactly the behavioral context an agent needs.

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?

Dense but front-loaded: purpose first, then cost mechanics, then background/polling. Every sentence carries meaning, though the coin/estimate/transcribe detail packs several clauses into one long sentence, slightly straining readability.

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 an 11-parameter, no-output-schema start tool, the description covers the crucial unknowns: free vs paid, coin spending, price-guard behavior, background execution, and idempotency. No output schema is needed since get_breakdown is named as the retrieval path.

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 value beyond the schema by tying expected_total to estimate_breakdown's quote ("pass expected_total exactly as estimate_breakdown priced it") and by framing the label/transcribe cost interaction. Most other parameters remain schema-only, so it stays short of 5.

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?

Opens with a specific verb and resource ("Start a shot breakdown of a video clip") and immediately distinguishes the free measured mode from the paid AI-read mode. It visibly separates itself from siblings estimate_breakdown (pricing), get_breakdown (polling), and label_breakdown (post-hoc labeling).

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?

Explicitly states when each mode applies (label:true vs false), directs the agent to estimate_breakdown for the price and to poll get_breakdown after starting, and explains the transcribe prerequisite (needs label). The alternatives and their selecting conditions are named, not inferred.

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

All Veltake Design 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?