Skip to main content
Glama

save_season_script

Destructive

Free, generates nothing. After the season plan is approved and before the paid create_series. Episode 1 first (the interview's default, and Just go): save only Episode 1's script before casting. After Episode 1 is delivered the customer chooses: the next episode alone (save_episode_script, its price, and on the yes make_episode, which holds that episode's own price), or the rest of the season here on one yes. The whole season now: write every episode's script from its plan row, in order, one call each. The same episode JSON as save_episode_script. 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. The first call needs series: the create_series arguments the season is cast with (title, language, premise, lead_a_* and lead_b_* fields, locations, cast; format and quality are the plan's); passing it again changes them and checks every script again. Each script is validated, auto-fitted and craft-checked like check_episode_script (the cliffhanger type against the two episodes before it, the season's episode length) and priced: video, voices and storyboards for this account. A plan change makes that episode's script and every later one stale until saved again. A change after the customer's yes keeps that yes and its held price while the season price stays within the approved max_credits (nothing is asked again); only a price above it gives the held price back (before casting) or waits for one new yes. Returns every script with craft_check, price and stale, casting_credits, total_credits (the season price), scripts_hash, say and next.

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_season_script"
  }
}

Input Schema

NameRequiredDescriptionDefault
nYes
seriesNo
episodeYes
series_idYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.4/5.0
Behavior5/5

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

Beyond the annotations it discloses server-enforced script rules (place ordering, lead on screen every scene, max people, newcomer cutoff), validation/auto-fit/craft-check behavior mirroring check_episode_script, per-account pricing, staleness propagation on plan changes, and the price-hold semantics after a customer yes. That is unusually rich behavioral context for a mutating tool, and it does not contradict the destructive/openWorld hints.

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?

The information density is high and most sentences carry real payload, but the prose is a dense run-on with parenthetical asides ('the interview's default, and Just go') and a confusing opening. It is long and poorly front-loaded rather than padded, so it earns a middling score.

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?

No output schema exists, yet the description enumerates the returned fields (craft_check, price, stale, casting_credits, total_credits, scripts_hash, say, next), covers the nested series/episode objects, and explains staleness and re-validation. An agent could call this correctly without further documentation.

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?

With 0% schema description coverage the description must carry the params, and it largely does: 'series' is explained as the create_series arguments cast with the season including which fields matter, re-passing it changes them and re-checks every script; 'episode' is defined by reference ('The same episode JSON as save_episode_script'); 'n' is implied by the one-call-per-episode ordering. 'series_id' is only implied, which keeps it short of a 5.

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 definition states the concrete action: write and save every episode's script from its plan row, one call per episode, and distinguishes it from save_episode_script (single next episode) and the paid create_series. The opening phrase 'Free, generates nothing' is cryptic and delays the verb, but the resource and scope are unambiguous once read.

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?

It gives explicit ordering ('After the season plan is approved and before the paid create_series'), a default ('Episode 1 first... save only Episode 1's script before casting'), and named alternatives with the condition that selects them ('the next episode alone (save_episode_script)... or the rest of the season here on one yes'). Nothing about tool choice is left to inference.

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