Shoot Plan

Check a take log against its plan

shoot_plan_validate_takes

Read-only

Checks a log of takes against the plan it was shot from, before you rely on it. It finds shots that are not in the plan, take numbers used twice, one op_id used for two different takes, file names written as paths, and a log made for another film or another revision of the plan. Each problem has a path into the log and a fix. A log with errors is a normal answer, not an error. The log is text about recordings (shot ids, verdicts, file names, timecodes). The tools take text only, never video or audio, and no AI model runs. Input: plan (a dpl.plan/1 object) and takes (a dpl.takes/1 object). Output: dpl.diagnostics/1 with valid (true or false) and each diagnostic with its fix. 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_validate_takes"
  }
}

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.
`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.

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

AddedOct 26, 2026

TDQS

A4.1/5.0

Behavior5/5

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

Beyond the annotations, the description discloses that validation errors are normal results, that each diagnostic includes a path and a fix, that the tool operates only on text, and that no AI model runs. It also states retention behavior, authentication requirements, free-tier treatment, size limits, and rate limits, which is unusually complete behavioral context.

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 description is front-loaded with purpose and validation targets, and most sentences carry useful operational detail. It is dense and somewhat long, with some repetition around text-only inputs, but remains appropriately sized for the tool's complexity.

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?

The description covers what the tool does, what it returns, how diagnostics should be interpreted, input constraints, authentication, retention, and rate limits. With an output schema present, it does not need to explain return structure in depth, and the remaining context is complete for correct invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so both parameters are already well documented in the schema. The description only restates that plan is a dpl.plan/1 object and takes is a dpl.takes/1 object, adding no significant syntax or format detail beyond the schema.

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 states a clear verb and resource: checks a take log against the plan it was shot from. It adds concrete validation targets such as unknown shots, duplicate take numbers, and reused op_id values, so the tool's purpose is specific. It does not explicitly distinguish itself from nearby siblings like shoot_plan_check or shoot_plan_merge_takes, which keeps it from a 5.

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?

The phrase 'before you rely on it' gives a clear usage context, and 'A log with errors is a normal answer, not an error' is an important invocation guideline. It does not name exclusions or explicitly compare to alternatives such as shoot_plan_check, so it falls short of full when/when-not guidance.

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?