AI Video Atlas

plan shots

plan_shots

Read-onlyIdempotent

Goal: a usable take on the first generation, so fewer paid generations per shot. First review and rewrite the beat list (see brief_review): Atlas parses briefs with rules, so fix non-shots, missing subjects, placeholder lines and generic coverage before writing prompts. If the user names a model or mode, pass it in model/mode (it is kept for every shot unless the docs rule it out). Returns a GUIDANCE PACKAGE, not final prompts: you (the agent) write each full video prompt yourself from it. Per shot: model + mode decision with reasons, the per-model/per-mode prompt structure and tips, 2-3 credited proven example prompts, capabilities/limits/prices with sources, techniques and director rules (practitioner hints at low weight), required assets with image-gen guidance, an 11-section quality checklist, and a starter draft (starting point only, never paste it as-is). If the user names a model or mode, pass it in model/mode (or keep it verbatim in description): Atlas keeps it for every shot unless the vendor docs rule it out, and explains why in user_named. Write each final prompt as flowing, sectioned prose sentences (subject/action, camera/lens/movement, location/light/color, style, audio), never field labels like speaker_id: or Subject:, and without stock filler phrases. Also returns intake (questions to ask the user + stated assumptions) and package_markdown (readable). Plan a multi-shot AI video from a plain description (deterministic, built only from Atlas data; no AI generation). Output is staged: decide (model/mode/clip length/aspect/cost with reasons and capability checks), direct (shot list with per-model prompts), assets (every reference/frame with status needs-generation|user-supplied|approved), image_prompts, and steps, which include a STOP: get the user to approve assets before generating any video. Global directives (same X in every shot, vertical, no text, style) apply to all shots; questions and request wording are never planned as shots; an explicit shot count is honored; clips longer than an endpoint's documented max are split. The description is split into beats (sentences, clauses, and cues like "then", "cut to", "close-up", "wide"). For each beat it returns a shot type; a recommended model endpoint with its current vendor-stated $/s and source; the generation mode to use (t2v, i2v, reference-to-video, start/end frame, v2v, lip sync; only modes the vendor docs confirm) with a one-line reason; image prompts for any input frames, plus a shared character/product reference sheet when shots must match; an adapted prompt built from the best-matching sourced example (credited and linked), an estimated cost (5 s per shot by default), and a how-to workflow when one applies (lip sync, consistent character…). It also returns a total. budget_usd (total) and/or max_per_shot steer it to cheaper supported endpoints; each shot also offers a cheaper alternative with its cost, and the plan says if the budget can't be met. Use this for "plan / storyboard / make me a video of…" requests; use find_shot for a single shot. Before presenting, adapt the wording to the user's voice, context and brand (names, tone, product details), but keep the prices, models, modes, clip lengths and reference tags exactly as returned.

Input Schema

Name	Required	Description
`mode`	No	Generation mode the user named. Kept for every shot unless the model cannot do it.
`model`	No	Model the user named (e.g. "Seedance 2.5"). Atlas keeps it for every shot unless the vendor docs rule it out, and then says why. Always pass it when the user names one.
`style`	No	Optional look applied to every shot, e.g. "35mm film, warm grade" or "anime".
`retries`	No	Optional retry allowance as a cost multiplier (e.g. 1.5 = budget 50% extra generations for rejected takes).
`budget_usd`	No	Optional total budget in USD.
`force_plan`	No	Return a shot plan even when the request reads as a pricing-only question
`description`	Yes	What the video should show, in plain words. Several beats are fine.
`clip_seconds`	No	Seconds per shot (default 5).
`max_per_shot`	No	Optional maximum USD per shot.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 11, 2026

addedInput schema / properties / retries

Added value: +{
+  "description": "Optional retry allowance as a cost multiplier (e.g. 1.5 = budget 50% extra generations for rejected takes).",
+  "type": "number"
+}

Changed2 schema fields changedOct 11, 2026

addedInput schema / properties / mode

Added value: +{
+  "description": "Generation mode the user named. Kept for every shot unless the model cannot do it.",
+  "enum": [
+    "text-to-video",
+    "image-to-video",
+    "reference-to-video",
+    "start/end frame",
+    "video-to-video"
+  ],
+  "type": "string"
+}

addedInput schema / properties / model

Added value: +{
+  "description": "Model the user named (e.g. \"Seedance 2.5\"). Atlas keeps it for every shot unless the vendor docs rule it out, and then says why. Always pass it when the user names one.",
+  "type": "string"
+}

First observedOct 11, 2026

TDQS

A4.4/5.0

Behavior5/5

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

Annotations only declare a safe, deterministic, idempotent read. The description adds substantial behavior beyond that: deterministic output built only from Atlas data with no AI generation, the staged decide/direct/assets/image_prompts/steps output, a mandatory STOP for user asset approval, sourced vendor pricing, and the statement that returned prices/models must be kept verbatim. This is exactly the extra context annotations cannot carry.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The lead ('Goal: a usable take on the first generation…') is front-loaded and useful, but the body is an undifferentiated wall of text. The model/mode instruction is repeated nearly verbatim ('If the user names a model or mode, pass it in model/mode…' appears twice), which is wasted ink in an otherwise long description.

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?

With no output schema, the description carries the full burden and largely does: it enumerates the staged return (model/mode decision, prompt structure, example prompts, assets, checklist, draft, intake, package_markdown, totals) and the budget behavior. It is complete, though the density makes the return shape harder to parse than it needs to be.

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: model/mode are 'kept for every shot unless the vendor docs rule it out' with an explanation surfaced in user_named, budget_usd/max_per_shot steer to cheaper supported endpoints and report when the budget can't be met, and retries acts as a cost multiplier. That goes beyond the schema's wording.

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?

The description states a specific verb+resource: it plans a multi-shot AI video from a plain description and returns a 'guidance package, not final prompts'. It explicitly distinguishes itself from a sibling ('use find_shot for a single shot'), so an agent can route between them without opening schemas.

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?

It names the trigger phrases ('plan / storyboard / make me a video of…') and routes single-shot requests to find_shot. It also explains steering via budget_usd/max_per_shot and force_plan. No explicit 'do not use when' beyond the sibling split, so not quite a 5.

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

All AI Video Atlas 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.

plan shots

Input Schema

Schema Changelog

TDQS

Glama MCP Gateway

Resources