Skip to main content
Glama

FilmLab

by com.thefilmradar
OverviewDiscussionsAdmin

Run Proposal

lab_run_proposal

Run a proposal exactly as shown — same model, same parameters, same price. Called by the card's button, or by you after the user confirmed. Single use: the proposal is consumed BEFORE the run, so a second call is refused instead of paying twice. Valid 15 minutes, for the account that created it. Costs credits. The run is checked against what you confirmed only when it FINISHES; poll lab_job_status and read review there. This answer carries review only if the run completed synchronously.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
vorschlag_idYesThe id from lab_propose or plan_b in lab_job_status. Do not construct one — an unknown id answers 'vorschlag_abgelaufen', not an error you can work around.
ohne_keyframeNoSkip the keyframe checkpoint on purpose. By default a paid clip only starts from a start image the user has approved (lab_review_asset verdict: accepted) — look at the frame first, then spend on the clip. Set true only when the user explicitly asked to skip the frame check.
prompt_overrideNoReplace ONLY the prompt text of the stored proposal. Every other parameter — model, resolution, duration, references — and the price stay exactly as shown. This is the path for a prompt the user edited on the card: the price does not depend on the text, so no new proposal is needed. Standbild-Bewegung uses no model prompt; confirm that proposal unchanged.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / additionalProperties
      Added value: +false
  2. Changed2 schema fields changed
    • changedInput schema / properties / prompt_override / description
      Previous value: -"Replace ONLY the prompt text of the stored proposal. Every other parameter — model, resolution, duration, references — and the price stay exactly as shown. This is the path for a prompt the user edited on the card: the price does not depend on the text, so no new proposal is needed."New value: +"Replace ONLY the prompt text of the stored proposal. Every other parameter — model, resolution, duration, references — and the price stay exactly as shown. This is the path for a prompt the user edited on the card: the price does not depend on the text, so no new proposal is needed. Standbild-Bewegung uses no model prompt; confirm that proposal unchanged."
    • changedInput schema / properties / vorschlag_id / description
      Previous value: -"The id from lab_propose. Do not construct one — an unknown id answers 'vorschlag_abgelaufen', not an error you can work around."New value: +"The id from lab_propose or plan_b in lab_job_status. Do not construct one — an unknown id answers 'vorschlag_abgelaufen', not an error you can work around."
  3. First observed

TDQS

A4.6/5.0
Behavior4/5

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

Goes well beyond the annotations: consumption happens BEFORE the run so a retry is refused rather than double-charged, the proposal expires in 15 minutes and is tied to the creating account, credits are spent, and confirmation is only checked at FINISH time. Annotations only supply the generic readOnlyHint=false/destructiveHint=false pair, so this added cost, idempotency and timing context is the real value.

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?

Purpose and cost/single-use constraint are front-loaded, and every sentence carries information. It is dense and slightly telegraphic (fragment-style clauses, mid-sentence language switches), but there is little pure 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?

With no output schema, the description correctly tells the agent where the result lives (lab_job_status / job review) and when review is returned inline. For a paid, single-use invocation tool this covers everything needed to call it safely.

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 100%, so the baseline is 3; the description still adds routing meaning, notably that prompt_override is the correct path for a card-edited prompt because the price does not depend on the text and no new proposal is needed.

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 ('Run a proposal') plus constraining scope ('exactly as shown — same model, same parameters, same price'), which separates it from lab_propose (creates proposals) and from the many lab_generate/lab_animate siblings. The id provenance ('from lab_propose or plan_b in lab_job_status') further anchors it.

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?

Explicitly names the two legitimate triggers (the card's button, or the agent after user confirmation) and redirects to lab_job_status for the final verdict, including the synchronous case. The single-use refusal and 15-minute/account-bound validity give clear when-not conditions.

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

All FilmLab toolsInspect
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