Shoot Plan

Cut a smaller plan out of a big one

shoot_plan_slice

Read-only

Cuts out part of a plan, so that you can send a smaller plan when your context is short: the scenes, the shots or the sequence you name, with everything they refer to (characters, places, props, sound and the rest) and their times unchanged. The slice is a valid plan of its own, so you can send it to shoot_plan_check, and it says which whole plan it was cut from (slice_of). It is for reading and editing one part: to change the film, change the whole plan and check that. Input: plan, and exactly one of scenes (scene ids), shots (shot ids) or sequence (one sequence id). Ids may be a name, a comma-separated list, or a list of names. An id the plan does not have is refused, and the refusal says what to change. Output: the sliced dpl.plan/1 with slice_of. A slice of shots that leaves gaps in a scene is judged as if the shots on either side of a gap were neighbours: treat its check as advice. No AI model runs. 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_slice"
  }
}

Input Schema

Name	Required	Description
`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.
`shots`	No	Slice these shots: shot ids (a name, a comma-separated list, or a list of names).
`scenes`	No	Slice these scenes: scene ids (a name, a comma-separated list, or a list of names).
`sequence`	No	Slice this one sequence: a sequence id.

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?

Goes well past the readOnlyHint/openWorldHint annotations: discloses that no AI model runs, the plan is not retained but a one-way hash, size, tool, client type, result and duration are logged, an agent key is required, and quota/rate limits (8 MB, 120 calls/min, 5,000/day) apply. It also warns that a slice with gaps is judged as if adjacent shots were neighbours, so its check is advisory.

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 the purpose and the selection constraint, and most sentences carry operational weight. The operational/logging paragraph is long but consists of distinct disclosure facts; a little tightening (repeating the id formats already in the schema) would help.

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 invocation rules, the XOR constraint, error behavior on unknown ids, the slice_of marker, caveats about gap semantics, auth, quotas, and side effects. An output schema exists, so the brief output note is sufficient; nothing an agent needs 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 schema already documents each parameter; the description adds the non-schema-enforceable constraint that exactly one of scenes, shots or sequence must be supplied, and repeats the id formats. The one real gap is that the id format rules duplicate the schema rather than adding new detail.

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 ('Cuts out part of a plan') plus the reason (send a smaller plan when context is short) and exactly what is carried over (scenes, shots, sequence plus referenced entities and times). This clearly separates it from siblings like shoot_plan_get or shoot_plan_diff.

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?

Explicitly frames itself as a read/edit aid: 'It is for reading and editing one part: to change the film, change the whole plan and check that.' It names the downstream consumer (shoot_plan_check) and states the alternative path for real edits, so when-not-to-use is clear.

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?