Shoot Plan

Start drafting a shot plan from a brief

shoot_plan_draft_start

Read-only

Starts a shot plan for you to write: from a short brief it returns a valid skeleton plan (the places to write start with TODO), the layers to write it in, shot-pattern recipes for common kinds of scene, and the first thing to do. The loop is: you write the plan, we check it. We write none of the film and no AI model runs. The brief is sent to us only to build the skeleton, and we don't keep it. Input: brief, a dpl.brief/1 object: title, target_runtime_ms and profile ("film", or "short" for a phone or small-crew shoot), and optionally logline, thesis, characters, places and, for a short, delivery, kit, people and shoot_window. Output: dpl.draft/1, with a skeleton plan that already validates, and next_tool, the tool to call next. Write the first layer into the plan, then follow next_tool. The engine's own wording may name its command line: ignore that and follow next_tool, which names the tool to call next and what to send. A brief with a mistake is refused with each problem and its fix. We don't keep the brief. 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": {
      "brief": "<brief>"
    },
    "name": "shoot_plan_draft_start"
  }
}

Input Schema

Name	Required	Description	Default
`brief`	Yes	The brief: a dpl.brief/1 JSON object with title, target_runtime_ms (whole milliseconds) and profile ("film", or "short" for a phone or small-crew shoot); optionally logline, thesis, characters, places and, for a short, delivery, kit, people and shoot_window.

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

AddedOct 26, 2026

TDQS

A4.4/5.0

Behavior5/5

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

With annotations already declaring readOnlyHint=true and openWorldHint=false, the description adds substantial operational context: no AI model runs, no film is written, the brief is not retained, a one-way hash and metadata are logged, an agent key is required, and limits are 8 MB / 120 calls per minute / 5,000 per day. This is exactly the kind of behavior an agent cannot infer from schema or annotations alone.

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, then workflow, input/output, routing, privacy, logging, auth, and limits. It is appropriately thorough for a complex entry-point tool, though there is minor repetition such as stating twice that the brief is not kept.

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 the full call lifecycle: required brief shape, returned draft and next_tool, error behavior for invalid briefs, privacy and logging, authentication, and usage limits. With an output schema present, this is more than enough for an agent to invoke the tool correctly.

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 the nested brief object and its fields are already well documented. The description repeats the key fields and optional fields, adding little parameter-level meaning beyond the schema, which is consistent with the baseline of 3 when the schema does the heavy lifting.

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 and resource: it starts a shot-plan draft from a brief and returns a validated skeleton plan, layers, recipes, and a next step. The loop 'you write the plan, we check it' clearly positions it against the checking and writing siblings, so an agent can tell what this tool is for without opening another schema.

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 explains the workflow: send a brief, receive a skeleton, write the first layer, then follow next_tool. The routing via next_tool is explicit and useful. It does not name when to prefer this over a sibling such as shoot_plan_create, so it stops short of full when/when-not/alternative 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?