agent-media

approve_season_scripts

Holds credits, generates nothing. Record the customer's one yes to every season script and the season price together: scripts_hash and max_credits exactly as get_season_scripts returned them, after the customer saw say. The price is priced again and held on the account as the season's spending authority: every paid step of the series (casting, voices, storyboards, video, retakes) is drawn from it and never charged above it. approval.state active: film Episode 1 now (create_series with create_series and dry_run false, then make_episode for n 1). pending_funding: the account does not hold that price yet; once it is paid, the same create_series holds it first. Refused while any script is missing, stale, failing or unpriced, or when the price moved since it was shown (show it again).

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>",
      "scripts_hash": "<scripts_hash>",
      "max_credits": "<max_credits>"
    },
    "name": "approve_season_scripts"
  }
}

Input Schema

Name	Required	Description	Default
`series_id`	Yes
`max_credits`	Yes
`scripts_hash`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

AddedNov 6, 2026

TDQS

A4.1/5.0

Behavior5/5

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

Beyond the annotations (which only say it is a non-read-only, non-destructive, open-world call), the description explains the credit-hold mechanism: the price is re-priced and held as the season's spending authority that every paid step draws from and is never charged above. It also discloses the two outcome states and the exact refusal cases (missing, stale, failing, unpriced scripts, or a moved price).

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 core action and the credit-hold consequence are front-loaded, and most clauses carry real information. However the prose is dense and partly garbled ('after the customer saw say'), which costs clarity on an otherwise information-rich definition.

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 three-parameter approval tool with no output schema, the description covers input provenance, the credit-hold side effect, refusal conditions, and the next call to make in each resulting state (approval.state active vs pending_funding). It is nearly self-sufficient, with only the sibling approval/release tools left unaddressed.

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 carries the burden, and it meaningfully explains two of three parameters: scripts_hash and max_credits must be passed through exactly as get_season_scripts returned them, and max_credits is the price ceiling for the whole season. series_id is left to inference, and no formats or type constraints are added.

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: record the customer's single approval of every season script plus the season price, and explicitly notes it 'generates nothing' while 'Holds credits'. It distinguishes itself from get_season_scripts (source of inputs) and create_series/make_episode (follow-ups), though it never contrasts with the similarly-named release_season_scripts or approve_season_plan.

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?

Clear preconditions are given: call only after the customer has seen the scripts, passing scripts_hash and max_credits exactly as get_season_scripts returned them, and the description explicitly routes post-approval behavior by state (active → create_series then make_episode; pending_funding → pay first). Refusal conditions are enumerated, but no guidance is offered on choosing this over release_season_scripts or approve_season_plan.

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

All agent-media tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?