Skip to main content
Glama

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. While a run is not done, the answer carries naechste_abfrage_s — wait that long before the next call instead of polling in quick succession; spaetestens_s (video) is the point after which the backend gives up and refunds. 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. Rights class is returned as rechte_klasse (klasse + regelstand) on result rows: mitgebracht, generiert, abgeleitet or lizenziert; nicht_festgehalten means the old row has no recorded class. This is separate from eigen/ki (AI Act).

Input 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.2/5.0
Behavior5/5

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

The annotations only declare readOnlyHint=true, but the description adds substantial behavioral context beyond that: why both project_id and id are required, how status values behave, the meaning of naechste_abfrage_s and spaetestens_s, the one-time nature of review, plan_b human-confirmation rules, and metadata details for kamerapfad, references, and rights class. No behavior contradicts the read-only 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 description is front-loaded with the core purpose and polling mechanics, but it becomes very long and dense, with multiple run-on clauses covering review, plan_b, kamerapfad, reference measurements, and rights class. Most details are useful, but the structure could be tighter and easier to scan.

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 a readOnlyHint annotation, the description carries the return-value burden and does so extensively. It explains status values, completion URLs, polling delays, review fields, plan_b behavior, kamerapfad metadata, reference scaling, and rights class, which is enough for an agent to interpret the likely response without a formal output schema.

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 already 100%, so the schema carries most parameter detail. The description still adds meaningful semantics by explaining that the backend has no single-item status endpoint and therefore both project_id and id are required, with id alone insufficient. It does not add much about type, wait_s, or preview beyond what the schema already says.

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?

The description gives a specific verb and resource: polling the status of an image or video generation started by lab_generate/lab_animate. It also explains the backend limitation that forces filtering the project list. It does not explicitly distinguish this from sibling status tools such as lab_get_job, lab_batch_status, or lab_vfx_status, so it falls short of full sibling differentiation.

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?

Usage is clear: call this after starting a generation via lab_generate or lab_animate, and use the returned next-poll delay rather than polling quickly. It also gives a strong rule for plan_b alternatives: present them to the human and never start them yourself, then call lab_run_proposal only after confirmation. It does not explicitly say when to prefer another status-like sibling tool, so it stops short of a 5.

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