Skip to main content
Glama

FilmLab

by com.thefilmradar
OverviewDiscussionsAdmin

Generation Status

lab_job_status
Read-only

Poll the status of an image or video generation started by lab_generate/lab_animate. There is no single-item status endpoint on the backend — this fetches the project's full image/video list and filters by id, so it needs BOTH project_id and id (the id alone is not enough). status inside the returned item's metadata is 'pending'|'completed'|'failed'; when completed, image_url/video_url is populated. When the run is done, the answer may additionally carry schritte (the step trail of this run) and review (a machine check against the confirmed brief, present once for a run that went through lab_propose/lab_run_proposal — absent for a still-pending run, a run started outside a proposal, or a repeat poll after the one-time check already ran): abweichung lists every field that came back different from what was confirmed, possibly empty; tool means the provider fallback chain degraded the run; bild means a vision check found the result contradicting an explicit statement of the brief (free for the user, once per run; bild_review says why it was skipped). A failed or degraded proposal run may also carry plan_b: alternatives with checked prices and proposal IDs, offered once. Present them to the human; never start them yourself. Call lab_run_proposal only after the human confirms an alternative.For a run that carried a kamerapfad, metadata.kamerapfad says what arrived and, as angewandt, WHICH form of it was actually sent — als_text (prose), als_regiebefehle (bracketed director commands, MiniMax/Hailuo), eigene_regie (the prompt already carried bracketed commands, so the path was deliberately NOT added next to them — eigene_regiebefehle lists them) or nicht_ableitbar (nothing of the path reached the prompt, with the reason). sprache next to it names the family rule and the source it rests on. For a reference-motion run, metadata.referenz_masse is the reference trail: one row per reference with what it measured (original_px) and, if the backend had to scale it to the model's limits, what it became (angepasst_px) and the address that was actually sent. Look there when a result ignores a reference or looks softer than the source — a silently rescaled reference looks like a badly generated one.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
idYesThe id returned by lab_generate (image) or lab_animate (video)
typeYesWhether the id refers to a generated image or a generated video
wait_sNoWait up to this many seconds (max 80) until the result is rendered AND its prompt check (abgleich) is in, or it failed — instead of polling in quick succession. The answer says gewartet_s. tool_id is the catalog id even after tool_used switched to the display label.
previewNoAttach the image itself, downscaled to 512px, so it can be LOOKED at instead of described. Costs one extra fetch and adds roughly 15-25 KB to the answer. Videos carry no still and return no picture — that needs a contact sheet, which is not built yet. Without this flag the answer is unchanged.
project_idYesProject id — required, since there is no global id lookup

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 / wait_s
      Added value: +{
+  "description": "Wait up to this many seconds (max 80) until the result is rendered AND its prompt check (abgleich) is in, or it failed — instead of polling in quick succession. The answer says gewartet_s. tool_id is the catalog id even after tool_used switched to the display label.",
+  "maximum": 80,
+  "minimum": 0,
+  "type": "integer"
+}
  3. First observed

TDQS

A4.1/5.0
Behavior5/5

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

Annotations only declare readOnlyHint, so the description carries the real burden and does so richly: status enum semantics ('pending'|'completed'|'failed'), which fields populate on completion, the one-time nature of the review check, why bild is free, that a silently rescaled reference looks like a bad generation, and the human-confirmation gate on plan_b. This is genuine behavioural disclosure well beyond the annotation.

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 purpose and the project_id+id constraint are correctly front-loaded, but the body is an unusually long wall of text dense with German field names whose names duplicate the schema (kamerapfad, referenz_masse, abweichung, angewandt). Much of it concerns rare edge cases, so signal-to-noise is worse than the content deserves.

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 must explain return values and does so exhaustively: the shape of status/metadata, image_url/video_url, schritte, review, plan_b, kamerapfad, sprache and referenz_masse, including the conditions under which each is present or absent. Nothing an agent needs to interpret a poll result is missing.

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 all five parameters are already documented in the schema. The description does reinforce why BOTH project_id and id are needed ('the id alone is not enough'), which is useful, but it repeats the schema's own rationale rather than adding syntax or format detail the schema lacks. Baseline 3 is appropriate.

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?

States a specific verb and resource: it polls the status of an image/video generation started by lab_generate/lab_animate, and explains that the backend has no single-item status endpoint so it filters the project's full list. It separates itself from the starter tools but never distinguishes itself from close siblings like lab_get_job, lab_batch_status or lab_jobs_inflight, which an agent could plausibly pick instead.

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 clear context for when to call it (after lab_generate/lab_animate), why wait_s is preferable to tight polling, when review/plan_b fields appear versus stay absent, and when to consult kamerapfad/referenz_masse. It also gives an explicit behavioural rule ('never start them yourself', only call lab_run_proposal after human confirmation), but offers no exclusion against the other status-like siblings.

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