Shoot Plan

Check a shot plan will cut together

shoot_plan_check

Read-only

Checks whether a shot plan will cut together before you film or generate it. It looks for crossed lines of action, mismatched eyelines, missing reactions, speakers who are never on screen, missing geography, jump cuts, travel direction, and props that change with no cause. It returns evidence from the plan and fixes it has already tested. The check is instant, and no AI model runs. It checks editing craft, not whether the film is good. Scenes without staging, dialogue or coverage detail come back "not assessed": call shoot_plan_missing_details for the questions to ask your human. Input: plan, a dpl.plan/1 object sent inline (call shoot_plan_format first if you have not written one). Optionally dispositions, the decision log that shoot_plan_record_decision gave you: a finding you decided about earlier, whose evidence has not changed, comes back closed with your reason, and one whose evidence has changed comes back open again (the answer then also says dispositions_applied: how many decisions were applied, reopened or matched no finding). Without dispositions the answer is the same as ever. Output: dpl.findings/1 with stable finding ids, plan_hash, rules_version, any not_assessed scenes and, per finding, its tested fixes (apply one with shoot_plan_apply_fix). A plan that does not validate gets dpl.diagnostics/1 instead: each problem with its path and a fix. We don't keep the plan. We log a one-way fingerprint (hash) of it, its size, the tool, the type of client, the result and the time taken. Needs an agent key from a Shoot Plan account. Free, and it does not count toward the account's 3 free projects a month. Plans up to 8 MB and 120 calls a minute (5,000 a day).

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": {
      "plan": "<plan>"
    },
    "name": "shoot_plan_check"
  }
}

Input Schema

Name	Required	Description	Default
`plan`	Yes	The plan itself: a dpl.plan/1 JSON object (not text inside a string). Call shoot_plan_format for the schema links and an example.
`dispositions`	No	The decision log: the dpl.dispositions/1 document shoot_plan_record_decision returned, exactly as returned. You keep it; we don't.

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

AddedOct 26, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Annotations only declare readOnly/openWorld; the description adds substantial context beyond them: no AI model runs, the plan is not retained but a one-way hash, size, tool, client type and timing are logged, an agent key is required, and limits are 8 MB / 120 calls per minute / 5,000 per day. It also discloses fallback behavior (dpl.diagnostics/1 on invalid plans) and the dispositions reopen/close semantics.

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-loaded with purpose and defect list, and nearly every sentence carries operational information. It is dense and somewhat run-on in the dispositions sentence, so not perfectly economical, but there is little filler.

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?

Covers input format, output shape (dpl.findings/1 with stable ids, plan_hash, rules_version, not_assessed scenes), error shape (dpl.diagnostics/1), auth, privacy, and rate limits. Even though an output schema exists, nothing an agent needs in order to call this correctly is missing.

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 goes well beyond the schema for dispositions: it explains how recorded decisions cause findings to come back closed or reopened, plus the dispositions_applied count. For plan it adds the precondition and inline-object constraint. This is meaningful added semantics, though a 5 is reserved for full clarity on both params.

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 ('checks whether a shot plan will cut together') and enumerates the exact defect classes it detects. It is clearly distinguishable from siblings like shoot_plan_missing_details and shoot_plan_apply_fix, both of which it names.

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 workflow ordering ('call shoot_plan_format first if you have not written one', 'call shoot_plan_missing_details for the questions to ask your human', 'apply one with shoot_plan_apply_fix'). It also states the boundary of the check ('editing craft, not whether the film is good'), which is a genuine when-not condition.

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

All Shoot Plan 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?