Skip to main content
Glama

make_episode

After script/quote approval, enqueue voices, storyboard for this episode, book, filming, ASR check, one paid retake for each scene that fails it (within the quoted replacement budget), edit and delivery. Returns immediately with progress.say (post it); then call get_episode with wait_seconds 40 until delivered. Repeated calls resume the same job. Refuses (started false, craft_check) while the saved script has craft_check issues; fix the script with save_episode_script instead of passing override_craft_check. 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. Warns when save_story_state was not saved through the previous episode. A series cast from a season plan films a new episode only from the approved current plan: otherwise started false with reason season_plan_* and say (post it as is). After an Episode 1 first start, make_episode after the customer's yes to a saved episode's script and price is that yes: it holds that one episode's price (never beside a held season price, never for an episode the season yes covers) and films it; no season approval is needed. It refuses with say (post it as is) while the episode before it is still being made (episode_hold_busy), out of order (episode_order), when the price rose above the one shown at save (episode_price_changed: show it again) or the account lacks the credits (insufficient_credits). A series in a language shows do not film never starts: started false, reason language_not_supported and say (post it as is). Checkpoints: before filming it returns started false, reason checkpoint_pending and show (the cast pictures, then the episode cover): show them, post say, and after the user's yes call approve_checkpoint, then make_episode again. The job then waits twice more (get_episode status awaiting_checkpoint: the storyboard, then scene 1 filmed). A season approved all at once stops only for the cast pictures; a checkpoint with no answer for 1 hour passes by itself. cover_url is the episode's cover.

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>"
    },
    "name": "make_episode"
  }
}

Input Schema

NameRequiredDescriptionDefault
nYes
series_idYes
override_craft_checkNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / override_craft_check
      Added value: +{
      +  "default": false,
      +  "title": "Override Craft Check",
      +  "type": "boolean"
      +}
  2. Added

TDQS

A4.5/5.0
Behavior4/5

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

Annotations only declare readOnlyHint=false, destructiveHint=false and openWorldHint=true, so the description must carry the rest – and it does: async return with progress.say, the checkpoint handshake via approve_checkpoint, the 1-hour auto-pass, resume semantics, price holds, and named refusal reasons (episode_hold_busy, episode_order, episode_price_changed, insufficient_credits, language_not_supported, season_plan_*). It stops short of describing the returned payload structure beyond progress/started/reason/say/cover_url, leaving some ambiguity about the full response shape.

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?

Front-loaded with the action, which is good, but the body is a dense run-on with repeated stock phrasing ('say (post it as is)' appears three times) and the four script rules plus writing guidance bundled into the same paragraph as failure modes. It is informative but hard to scan, and the writing guidance ('calm, natural acting') is not enforced and could be moved out.

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?

For a long-running, multi-stage, credit-consuming pipeline with no output schema, this covers the full lifecycle an agent needs: what starts, what blocks it, how to poll, how to clear checkpoints, and what each refusal reason means. Nothing essential to calling it correctly 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 0%, so the description must compensate. It gives strong semantics for override_craft_check (never lifts the four enforced rules; use save_episode_script instead), but n and series_id are left implicit – an agent infers n is the episode number but nothing states it, nor whether series_id comes from create_series or get_series.

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?

Opens with a specific verb and resource plus scope: after script/quote approval, enqueue voices, storyboard, book, film, ASR check, retake, edit, deliver. It is unmistakably distinct from get_episode (polling) and save_episode_script (fixing the script), so an agent can pick it without opening a schema.

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?

Gives explicit when-to-use (after script and quote approval; after the customer's yes to a saved episode's script and price), when-not (refuses while the saved script has craft_check issues – fix with save_episode_script instead of override_craft_check), and how to continue (poll get_episode with wait_seconds 40; repeated calls resume the same job). Alternatives are named rather than inferred.

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