Skip to main content
Glama

save_episode_script

Destructive

Validate and save an episode before production. Returns the video quote plus replacement budget, price (video, voices and storyboards, and guests when the episode has any: show price.total_credits), craft_check {passed, issues, warnings}, ready_to_film and (cast v2) cast_by_scene and episode_cast. Episode fields: cliffhanger_type (partial_reveal|reversal_setup|intrusion|ticking_clock|betrayal_reveal) and one turn (text) on the shot where the reversal lands, 10 to 20 s of a 30 s episode. Script rules (the server enforces these four; episodes that jump between places and people read as unrelated cuts): places only move forward: at most 3 places in an episode, never back to a place already left; a lead (a or b) is on screen in every scene; at most 4 people on screen in an episode; nobody new after 60% of the runtime, except one newcomer in the last scene of an intrusion cliffhanger. Writing guidance, not enforced: the first spoken line is the hook; the episode ends on a lead's line. Write calm, natural acting: no face-acting notes per line; the server directs camera and performance. make_episode's override_craft_check never lifts the four rules. Cast v2: every scene "cast" lists everyone featured in it (4 at most), the recurring characters too, not only the two leads: use the recurring cast across the season so it feels like a real series. Each character's full body and (once made) turnaround sheet go to the video model as references. Optional "guests": up to 2 one-episode characters [{id x1|x2 (or left out), name, gender, age, look, outfit, body_type, palette (a colour no one else wears), signature_prop?, voice_note?, function?}], adults only, names and palettes not used by the cast; each is cast for this episode only (face, full body and turnaround sheet, made when the episode is made) and priced in this quote (price.guests_credits, guest_images, guests_included); scenes list them by id in cast. Guest images are made only when the plan includes them (0 credits, as a drama plan includes casting), never charged: on a plan that does not, price.guests_note says so and the guests are described in words. A guest that cannot be made is described in words and the episode still films. Optional scene "background": a short line of unnamed extras in words (120 characters at most, e.g. "two nurses walking past, a crowd at the bar"), never named, never speaking, never in focus and never a reference image. The server fixes timing itself (a silent beat where the story is short, a scene up to 0.1 s over timed to its 10 s, a filler word cut from a line that runs long, a long pause tightened) and lists every change in fixed: show fixed with the script; the price is the fixed script's. Fix the craft_check issues left before showing the script; show script, check and price for approval before make_episode. Maximum 60 seconds.

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": {
      "series_id": "<series_id>",
      "n": "<n>",
      "episode": "<episode>"
    },
    "name": "save_episode_script"
  }
}

Input Schema

NameRequiredDescriptionDefault
nYes
episodeYes
series_idYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A3.9/5.0
Behavior4/5

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

Annotations declare a mutating, open-world, destructive operation; the description is consistent and adds real substance beyond them — the server autonomously rewrites timing and reports every change under 'fixed', four script rules are server-enforced and unbypassable, guest images are generated only on plans that include them and are never charged, and the quote returned reflects the fixed script. It does not state overwrite semantics (what happens to a previously saved episode script) or any auth/rate constraints, which is the notable gap for a destructive-hint tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Purpose and return shape are front-loaded, but the remainder is a single dense paragraph of run-on sentences and stacked parentheticals that is hard to scan; guest rules, script rules, timing behavior and cast-v2 guidance all blend together. Most content earns its place given the empty schema, but the lack of structure costs it.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a complex, destructive, open-world mutation with no output schema and 0% schema coverage, the description covers the return payload (price.total_credits, craft_check, ready_to_film, cast_by_scene, fixed), the enforced rules, and the pricing implications of guests. Remaining gaps are the meaning of n and series_id and the consequences of saving over an existing script.

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 description coverage is 0% and 'episode' is a free-form nested object, so the description carries the full burden — and it does so extensively, defining cliffhanger_type enum values, the single turn shot, guest object fields (id, name, gender, age, look, outfit, body_type, palette, signature_prop, voice_note, function), the 120-character background constraint, cast-by-scene semantics, and the 60-second cap. The two scalar parameters series_id and n are never explained, and the field documentation is embedded in prose rather than tied to 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?

Opens with a specific verb+resource: 'Validate and save an episode before production,' immediately telling the agent this both checks and persists an episode. It positions itself relative to make_episode ('show script, check and price for approval before make_episode') but never explicitly contrasts with the check_episode_script sibling, leaving some ambiguity about which validation entry point to call first.

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?

Gives concrete workflow sequencing: fix remaining craft_check issues, then 'show script, check and price for approval before make_episode,' and warns that make_episode's override_craft_check never lifts the four enforced rules. Lacks an explicit statement of when to use the sibling check_episode_script versus this tool, which is the main missing routing cue.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources