Skip to main content
Glama

FilmLab

by com.thefilmradar
OverviewDiscussionsAdmin

Model Catalog

lab_list_models
Read-only

The model catalog: what every video or image model can do — resolutions, durations, aspect ratios, audio, reference limits, price per second or per image — grouped by capability class with a one-line explanation per group. Read this before choosing a tool for lab_generate/lab_animate/lab_propose; copy ids verbatim. Cached briefly; stand says how fresh. Without klasse the answer is COMPACT (one line per model, cheapest first, plus klassen with every valid class name); with klasse or voll: true every field. Filter to answer the usual question directly: aufloesung, dauer_s, ton (ohne = models that can run silent, including switchable audio). A model with switchable audio is listed under the class with AND without sound (i2v_ton and i2v).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
tonNoohne = can run without sound (audio nie or schaltbar); mit = can make sound
kindYesWhich catalog
vollNoEvery field of every model even without klasse — large, use a filter with it
klasseNoOnly one capability class — the valid names are listed under `klassen` in every answer
dauer_sNoOnly models that can render this duration in seconds
aufloesungNoOnly models offering this resolution, e.g. 540p

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / additionalProperties
      Added value: +false
  2. Changed5 schema fields changed
    • addedInput schema / properties / aufloesung
      Added value: +{
+  "description": "Only models offering this resolution, e.g. 540p",
+  "type": "string"
+}
    • addedInput schema / properties / dauer_s
      Added value: +{
+  "description": "Only models that can render this duration in seconds",
+  "exclusiveMinimum": 0,
+  "type": "number"
+}
    • changedInput schema / properties / klasse / description
      Previous value: -"Only one capability class (e.g. the class name from a previous answer)"New value: +"Only one capability class — the valid names are listed under `klassen` in every answer"
    • addedInput schema / properties / ton
      Added value: +{
+  "description": "ohne = can run without sound (audio nie or schaltbar); mit = can make sound",
+  "enum": [
+    "mit",
+    "ohne"
+  ],
+  "type": "string"
+}
    • addedInput schema / properties / voll
      Added value: +{
+  "description": "Every field of every model even without klasse — large, use a filter with it",
+  "type": "boolean"
+}
  3. First observed

TDQS

A4.6/5.0
Behavior4/5

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

Annotations only declare readOnlyHint=true; the description adds real context beyond that — brief caching with a `stand` freshness signal, and the crucial output-shape behavior (COMPACT by default, full fields with klasse/voll). It stops short of documenting pagination or size limits, but discloses enough behavioral nuance to be genuinely useful.

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?

Dense and long, but front-loaded with the catalog's purpose and every sentence carries information (fields, routing, output modes, filtering). Minor cost from mixed-language inline tokens and run-on phrasing, but nothing is padding.

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 carries the burden of describing returns and does so — one line per model when compact, `klassen` listing every valid class, and full fields when klasse/voll is set. Combined with the 100%-covered input schema and readOnlyHint, an agent has everything needed to call it correctly.

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, but the description adds meaning on top: it explains the default COMPACT vs verbose behavior, the silent-audio semantics of `ton` (including switchable audio), and the AND-listing quirk where a switchable-audio model appears under both i2v_ton and i2v. That is value the schema alone does not convey.

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?

Opens with a specific resource ('the model catalog') and enumerates exactly what it contains — resolutions, durations, aspect ratios, audio, reference limits, pricing — and states it is grouped by capability class. The agent can immediately distinguish it from generation siblings like lab_generate/lab_animate because it is the read-only lookup that precedes them.

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 'Read this before choosing a `tool` for lab_generate/lab_animate/lab_propose; copy ids verbatim', naming the exact alternatives and the trigger condition. It also gives when-to-narrow guidance (filters, klasse, voll) so the agent knows how to invoke it for the common question.

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