Skip to main content
Glama

FilmLab

by com.thefilmradar
OverviewDiscussionsAdmin

Animate Batch

lab_animate_batch

Animate MANY images into videos in ONE call (max 25 jobs). Prefer this over looping lab_animate: it validates every job BEFORE spending any quota, so an invalid job 12 of 15 does not leave 11 paid-for generations running. Quota is spent once, collectively (one ledger row); refunds stay per-clip, so a partial failure refunds only that clip. Returns a batch_id — poll lab_batch_status with it instead of polling each id separately. get_cost: true preflights the whole batch without generating anything.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
jobsYesOne entry per clip, max 25. All jobs are validated before any quota is spent
get_costNoPreflight: return the summed price in credits for the WHOLE batch and your balance WITHOUT generating, reading the same catalog as lab_list_models. For a card the user confirms, use lab_propose instead.
project_idYesProject id (from lab_list_projects)
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.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / additionalProperties
      Added value: +false
  2. Changed1 schema field changed
    • addedInput schema / properties / jobs / items / properties / familie
      Added value: +{
+  "description": "Pick the MODEL, not the access route: 'seedance-2.0' or 'seedance-2.5'. The server takes the cheapest route that this account may use and that can do the job (OpenRouter only with the user's consent; references, 1080p for 2.5, or audio switched off go to fal) and falls back to fal if a cheaper route fails — the fallback can cost more than the preflight price. Mutually exclusive with tool and intent.",
+  "enum": [
+    "seedance-2.0",
+    "seedance-2.5"
+  ],
+  "type": "string"
+}
  3. First observed

TDQS

A4.7/5.0
Behavior5/5

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

Annotations only give readOnlyHint=false and destructiveHint=false, so the description carries the real behavioral burden and delivers: all jobs validated before quota spend, quota billed once collectively (one ledger row), per-clip refunds on partial failure, and a returned batch_id. These billing/validation/refund semantics are exactly the non-obvious traits an agent needs.

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

Conciseness5/5

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

Front-loads the core action and scope, then each following clause adds a distinct, non-redundant fact (validation ordering, quota pooling, per-clip refunds, batch_id polling, cost preflight). No filler sentences.

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 and only 2 required params, the description fills the gap by naming the return value (batch_id) and the correct follow-up tool (lab_batch_status), plus quota and refund behavior. An agent has everything needed to invoke and continue correctly.

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

Parameters3/5

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

Schema description coverage is 100%, so the baseline is 3. The only parameter mentioned, get_cost, largely restates its own schema text about preflighting price without generating, adding little beyond what the field already documents.

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 concrete verb+resource (animate many images into videos) with explicit scope (max 25 jobs, one call) and immediately distinguishes itself from the looping alternative lab_animate. An agent can tell what it does and how it differs from its closest sibling without opening either 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?

Explicitly says 'Prefer this over looping lab_animate' with the reason (pre-validation avoids orphaned paid generations), and routes the agent onward to lab_batch_status for polling and to get_cost for a dry run. When-to-use, when-not, and alternatives are all named.

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