Skip to main content
Glama

get_episode_script

Read-only

Full saved script: scenes, locations, shots, lines and speakers.

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

Input Schema

NameRequiredDescriptionDefault
nYes
series_idYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

C2.4/5.0
Behavior2/5

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

Annotations already declare readOnlyHint=true, openWorldHint=true and destructiveHint=false, so the safety profile is covered structurally, yet the description adds nothing beyond that — no note on whether the 'saved' script may differ from a generated one, what happens if no script exists yet, or whether upstream work must be complete first.

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?

A single short sentence with no filler and the content shape is front-loaded. Its brevity is really under-specification rather than economy, since key facts about parameters and return shape are simply absent.

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

Completeness2/5

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

With no output schema, no annotation detail on return values, and two undocumented required parameters, the description should carry the load — but it does not say what a 'script' object actually contains (JSON structure, nesting of scenes/shots) or what errors occur when no script exists.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%: series_id is unlabeled and n is a bare integer with no stated meaning (episode number? index? 0- or 1-based?). The description mentions neither parameter and only obliquely implies an episode selector, so it fails to compensate for the coverage gap.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose3/5

Does the description clearly state what the tool does and how it differs from similar tools?

The fragment names the resource (a full saved episode script) and enumerates its contents, so the object is identifiable. But there is no verb — nothing states that it retrieves/returns the script rather than saving it, and it is not distinguished from close siblings like get_episode, get_episode_storyboard or save_episode_script.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No when-to-use guidance, no prerequisites, and no exclusions. The set of siblings contains get_episode, get_episode_storyboard and save_episode_script, and the description gives an agent no basis for choosing among them.

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