Skip to main content
Glama

FilmLab

by com.thefilmradar
OverviewDiscussionsAdmin

Review Queue

lab_review_queue
Read-only

Browse GENERATED rows (images or videos) — newest first, each with the INPUTS it ran on. Every row carries inputs[] (start/reference images, reference videos, character refs — role + url) and params (model, mode, resolution, seed…). Read those before comparing two runs: a run without its inputs is a claim with a picture attached, and a comparison described as one-variable has more than once turned out to differ in three. An input whose URL was never recorded appears as origin: 'unrecorded' — that is a gap in the write path, NOT a text-to-* run. Two modes. PER PROJECT (pass project_id + type): adds the review filters — verdict, selected_only, scene_ref — and carries selected. ACROSS PROJECTS (omit project_id, or pass since/until/tool_used/cursor): the time-range view for 'what ran on August 3rd?'. The review filters do not exist there and are rejected rather than silently dropped. Page with next_cursor.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
typeNoWhich generated rows. Required per project; across projects, omit for both
limitNoMax rows (per project default 50). Across projects the page is capped at 20 so next_cursor stays exact
sinceNoACROSS PROJECTS. created_at >= this ISO-8601 timestamp (e.g. 2026-08-03T00:00:00Z)
untilNoACROSS PROJECTS. created_at <= this ISO-8601 timestamp
cursorNoACROSS PROJECTS. The next_cursor of the previous page. Opaque — do not build one by hand
previewNoAttach the pictures themselves, downscaled to 512px, so a generation run can be SORTED by looking instead of by reading prompts. At most 4 per call — narrow the list with scene_ref/limit rather than expecting more. Rows without an image URL (all videos) are named in preview.notes, not silently dropped.
verdictNoPER PROJECT ONLY. Exact verdict filter. Omit to get everything except rejected
scene_refNoPER PROJECT ONLY. Only this scene
tool_usedNoACROSS PROJECTS. Exact tool/provider name, e.g. seedance-2.5
project_idNoProject id (from lab_list_projects). Omit to search across all projects
selected_onlyNoPER PROJECT ONLY. Only the chosen variants
include_rejectedNoPER PROJECT ONLY. Include rejected in the default listing

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / additionalProperties
      Added value: +false
  2. First observed

TDQS

A4.8/5.0
Behavior5/5

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

With readOnlyHint already covering the safety profile, the description adds substantial non-obvious behavior: rows carry inputs[]/params, `origin: 'unrecorded'` signals a write-path gap rather than a text-to-* run, review filters are rejected in cross-project mode, and pagination uses next_cursor. These are behavioral traits an agent would otherwise get wrong.

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-loaded and information-dense, with the two-mode split clearly separated by a paragraph break. The aphoristic aside about runs and pictures is memorable but stylistically heavier than the rest, slightly blunting conciseness.

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?

For a 12-parameter tool with no output schema, the description covers the return shape (inputs[] with role+url, params, selected, next_cursor, preview.notes) and the limits (page cap of 20 across projects, 4 previews). Nothing needed to call or interpret the call is missing.

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 description coverage is 100%, so the baseline is 3; the description goes further by explaining the cross-parameter interaction that selects the two modes and the meaning of unrecorded origins. It does not add format or syntax detail beyond the schema for individual fields, so it stops short of 5.

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 precise verb+resource+ordering ("Browse GENERATED rows (images or videos) — newest first, each with the INPUTS it ran on") and distinguishes the two operating modes. An agent can tell this apart from list/asset tools like lab_list_assets or lab_review_asset by the generation-row scope and input-join behavior.

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 partitions into PER PROJECT vs ACROSS PROJECTS modes with selection criteria for each ("what ran on August 3rd?"). It also names the consequence of using the wrong filters ("rejected rather than silently dropped") and points to lab_list_projects as the source of project_id.

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