Skip to main content
Glama

check_episode_script

Read-only

Read-only, saves nothing. Same episode JSON as save_episode_script. Runs validation and auto-fit, then the mechanical craft check and the 30 s story grammar: first spoken line within 2 s (the hook), 25 to 45 spoken words per 30 s, lines at most 10 words (warn over 8), exactly one turn on the shot at 10 to 20 s of 30 s (both scale with the runtime), a cliffhanger_type that differs from the previous 2 episodes, no silent shot over 1.2 s except the final 1.5 s reaction, ends on a line or reaction within the last 3 s. 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. Cast v2: checks every scene cast (recurring characters and the episode's guests x1 and x2 included), the guests and each scene background (unnamed extras in words, never a reference image: the references are each character's full body and, once made, turnaround sheet), and warns when only the leads appear while the series has recurring characters. Timing is fixed, not handed back: 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; every change is listed in fixed and episode is the fixed script (send it on). Returns {passed, issues, warnings, episode, fixed, cast_by_scene, episode_cast}. Before the series exists, n 1 is checked against the series your last create_series dry run priced (series_created false); the dry run's own episode_1 field is the same check.

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": "check_episode_script"
  }
}

Input Schema

NameRequiredDescriptionDefault
nYes
episodeYes
series_idYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.1/5.0
Behavior5/5

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

Annotations only declare readOnly/non-destructive/openWorld, and the description goes well beyond them: it discloses that the server enforces four script rules, that timing violations are auto-fixed rather than returned as errors ('Timing is fixed, not handed back'), that each change is itemized in 'fixed', that cast v2 checks backgrounds and guests, and that only warnings are raised for some conditions. It even enumerates the exact return keys, which is genuinely useful since no output schema exists.

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?

Every clause carries real rule information, but the packaging is poor: multiple run-on sentences string rules, cast checks, fix behavior, and return keys together without bullets or paragraph breaks, and the return-shape information is tacked on at the end. For a rules-heavy tool some length is justified, but front-loading and segmentation are weak.

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 tool with a nested object parameter, no output schema, and zero schema coverage, this is unusually complete: it lists every returned key, explains the auto-fix semantics, states which rules are enforced versus advisory, and covers the pre-series dry-run edge case. An agent has enough to call it and to interpret the result 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 0%, so the description must carry the load. It does help by identifying the episode payload as 'the same episode JSON as save_episode_script' and by listing the content constraints the episode must satisfy, and it clarifies the n=1 pre-series case. However, it never states what series_id or n denote plainly, and the nested episode object is described only through rules rather than structure, so compensation is partial.

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 specific action chain: 'Runs validation and auto-fit, then the mechanical craft check and the 30 s story grammar,' and distinguishes itself from save_episode_script ('read-only, saves nothing. Same episode JSON as save_episode_script'). An agent can tell it apart from the save sibling. It loses a point because the core verb is preceded by two framing sentences and then buried under an enumeration of rules, so the purpose must be extracted rather than read.

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?

Usage context is clear: this is the non-persisting check whose 'episode is the fixed script (send it on),' which implies the check-before-save workflow, and the n=1 case is explicitly routed to the create_series dry run's pricing. What is missing is an explicit statement of ordering ('call before save_episode_script') and of when not to use it; the agent must infer the sequencing from 'send it on.'

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