Shoot Plan

Did we get it? What is covered and what is left

shoot_plan_coverage_status

Read-only

Answers "did we get it?" before the crew leaves a location: from the plan and the take log it says which must-have shots have no good take, which reactions or cutaways the edit will need are still missing, what must match on the next set-up, and whether room tone was recorded. A "hold" verdict is not yet a decision, so it does not count as covered and is asked about. The tools take text only, never video or audio, and no AI model runs. Input: plan and takes (a dpl.takes/1 log); optionally location, scene and day to look at one part of the shoot (each a string, comma-separated names allowed, or a list of strings; a name that is not in the plan is refused with a fix), and next_setup, the set-up that follows. Output: dpl.coverage-status/1. We don't keep the plan or the take log. 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>",
      "takes": "<takes>"
    },
    "name": "shoot_plan_coverage_status"
  }
}

Input Schema

Name	Required	Description
`day`	No	Optional: only these shoot days, as the plan's schedule names them.
`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.
`scene`	No	Optional: only these scene ids.
`takes`	Yes	The take log: a dpl.takes/1 JSON object, {format, work_id, takes: [...]}. Each take has op_id, shot (the plan's shot id), kind and verdict; file names and timecodes are optional. A take log holds text about recordings: the tools take no video or audio.
`location`	No	Optional: only these locations (a name, a comma-separated list, or a list).
`next_setup`	No	Optional: the set-up that follows, so the answer says what must match across the change.

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

AddedOct 26, 2026

TDQS

A4.3/5.0

Behavior5/5

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

With readOnlyHint=true and openWorldHint=false already given, the description still adds substantial context: a 'hold' verdict does not count as covered and is queried, only text is accepted (no video/audio), no AI model runs, the plan and take log are not retained, an agent key is required, and explicit limits (8 MB plans, 120 calls/min, 5,000/day) plus pricing notes are disclosed. These are exactly the traits an agent needs beyond the annotations.

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?

The core question ('did we get it?') is front-loaded and the input/output/operational facts follow in a logical order, with no repetition. It is a single dense block with long multi-clause sentences, and the pricing/rate-limit tail adds bulk, but nearly every sentence carries information an agent would otherwise have to guess.

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?

An output schema (dpl.coverage-status/1) exists, so return values need no prose, and all six parameters are covered with their edge behavior. Auth requirement, payload shape expectations (JSON object, not a string), input-size and rate limits, and data-retention behavior are all stated — nothing material is missing for correct invocation.

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; the description goes beyond it by explaining that location/scene/day narrow the shoot to one part, that each may be a string, comma-separated names, or a list of strings, and that a name not present in the plan is refused with a fix — behavioral semantics the schema does not state. next_setup is also explained as driving cross-set-up matching advice.

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?

The description concretely states the resource and the analysis: from plan + take log it reports which must-have shots lack a good take, which reactions/cutaways are missing, what must match on the next set-up, and whether room tone exists. That is far more specific than the title's 'did we get it?'. It does not, however, explicitly distinguish itself from close siblings such as shoot_plan_validate_takes, shoot_plan_check or shoot_plan_status, so an agent must infer the boundary.

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 gives a clear triggering context — 'before the crew leaves a location' — plus the optional next_setup use case, which tells the agent when the tool is worth calling. It never names an alternative tool or an explicit exclusion ('do not use this to validate the take log format; use X'), so the routing among coverage/status/validate siblings is left to inference.

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?