Skip to main content
Glama
seocombat

Clipwright

by seocombat
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

Revise a run

revise_run

Start a paid revision of a make_faceless video run: send changed shots or a full edited document to render a new version; quote_revision first shows the price.

Instructions

Start a revision of a run made by make_faceless (paid): a NEW run that renders the video again with the shots you change, by changes (a shot and what to generate for it) or by document (the whole edited document); pass exactly one. Call quote_revision first and show the user the price. An identical request returns the same run it started before, so a call repeated after a lost answer starts nothing new; to start a second revision with the same request on purpose, pass attempt 2. A revision that delivers is charged its quoted total; one that fails is charged nothing, even when its paid work was already done. An original has a limit on revisions running at once and on revisions failed or unfinished, and paid edits of it close some days after it finished; a refusal names which. While paid edits are closed it answers editing_disabled and charges nothing. The result is a new run: poll it with get_run; once it succeeded it is editable under its own run_id.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
run_idYesThe run to revise: a succeeded make_faceless run, an original or a revision.
attemptNo
changesNoShots to generate anew over the run as it is: each a shot_id and the operation to generate for it.
documentNoThe whole edited document, as the run's draft holds it; retimes, deletions and uploads go this way.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.28.0

TDQS

A4.8/5.0
Behavior5/5

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

Goes far beyond the readOnlyHint=false/destructiveHint=false annotations: it documents idempotency (identical request reuses the same run), billing semantics (charged on delivery, nothing on failure), concurrency limits on revisions, expiry of paid edits, and the editing_disabled refusal code. This is unusually rich behavioral disclosure for a write tool.

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-loads purpose and the quote-first rule, and nearly every clause carries distinct information (billing, idempotency, limits, output). It is nonetheless a dense semicolon-chained paragraph that could be tightened, but no clause is filler.

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?

Despite a complex nested schema, no output schema, and four parameters, the description covers cost flow, idempotency, failure/refusal behavior, and the return path (new run polled with get_run, editable under its own run_id). An agent has everything needed to call it correctly.

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?

Adds real meaning beyond the 75%-covered schema: it explains the changes vs. document distinction and, critically, the 'pass exactly one' exclusivity rule that the schema does not enforce. However, the nested operation modes (retake, new_picture, edit_picture, animate) and their description/instruction/motion fields are not explained in the description or schema, leaving that gap.

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 ('Start a revision of a run made by make_faceless') and immediately clarifies the output ('a NEW run that renders the video again'). It distinguishes itself from siblings by naming the originating tool (make_faceless) and the polling tool (get_run), so an agent can place it in the workflow without opening another schema.

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?

Explicit when-to-use and prerequisites: 'Call quote_revision first and show the user the price', 'pass exactly one' of changes/document, and idempotency handling via attempt 2. It also names an alternative surface (get_run for polling) and a failure mode (editing_disabled), leaving nothing about routing to inference.

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

Deploy Server

Other Tools