Skip to main content
Glama

Produce the video

produce
Destructive

Starts (or resumes) the production line of an EXISTING project: sets its drive to auto and dispatches the next station — the same sequence the human's «produce» button runs (enrich → studio build → final render). Publishing is not part of it. Applies to a project created without auto-production once edited, and to a line that stopped. The answer says whether the tick was really enqueued (dispatched, dispatch.reason) and what the line will do (line). On a piece whose final is already delivered, or whose final render failed before delivering, the line does not render again by itself: the answer then carries finalRender — whether the studio changed after the delivered final, or the failed run and its message, and the quote of a NEW final render — and with confirm_spend=true the new render is launched, the same act as the human's «produce again» in the studio. Requires write. Spends budget under the org's quota and the daily free-action cap (each call counts as one action).

Input Schema

NameRequiredDescriptionDefault
project_idYes
confirm_spendNoOnly for a piece whose final is already delivered or whose final render failed: true launches a new final render (a paid render, quoted in `finalRender.quote`). Default false: the answer quotes it and launches nothing.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / confirm_spend / description
      Previous value: -"Only for a piece whose final is already delivered: true launches a new final render (a paid render, quoted in `finalRender.quote`). Default false: the answer quotes it and launches nothing."New value: +"Only for a piece whose final is already delivered or whose final render failed: true launches a new final render (a paid render, quoted in `finalRender.quote`). Default false: the answer quotes it and launches nothing."
  2. Changed1 schema field changed
    • addedInput schema / properties / confirm_spend
      Added value: +{
      +  "description": "Only for a piece whose final is already delivered: true launches a new final render (a paid render, quoted in `finalRender.quote`). Default false: the answer quotes it and launches nothing.",
      +  "type": "boolean"
      +}
  3. First observed

TDQS

A4.6/5.0
Behavior5/5

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

Goes well past the destructiveHint/readOnly annotations by disclosing that the call requires write, consumes budget under the org quota and the daily free-action cap, and counts as one action. It also explains what the response carries (`dispatched`, `dispatch.reason`, `line`, `finalRender`, `finalRender.quote`) and that a new render only launches with confirm_spend=true.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with the core action and scoping before the conditional final-render branch. It is dense and long, with nested parentheticals about `dispatch.reason` and `finalRender` that slow an agent slightly, but nearly every sentence carries actionable information.

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?

There is no output schema, yet the description enumerates the meaningful response fields and their branches, so an agent knows what a successful call returns. Combined with the spend, auth, and idempotency caveats, nothing needed for correct invocation 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 50% and the description compensates by framing confirm_spend as 'only for a piece whose final is already delivered or failed' and describing the quoted-then-launched behavior. project_id is left implicit — only the phrase 'an EXISTING project' ties it to the required id parameter.

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?

States a specific verb and resource: starts or resumes the production line of an existing project, and spells out the internal sequence (enrich → studio build → final render). It also draws a boundary by saying publishing is not part of it, which separates it from the publishing/ops siblings.

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?

Gives concrete when-to-use conditions: a project created without auto-production that has since been edited, or a line that stopped. It also covers the when-not case (final already delivered or final render failed) and the confirm_spend escape hatch. It never names a competing sibling such as run_op or direct, so the exclusion is inferred rather than explicit.

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