Skip to main content
Glama
Sign In

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): fields that are null, false or empty are left out, and a model that also belongs to another class shows there only as a short stub whose wie_in names the class holding its full entry. form: knapp means the catalog was too large for one answer — set klasse for the details. 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

NameRequiredDescriptionDefault
euNoOnly models allowed in EU mode projects (data stays inside the EU data path). Every model carries `eu_modus` and, where false, `eu_grund` — the first missing proof (`form: knapp` carries only `eu_modus`)
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 / properties / eu
      Added value: +{
+  "description": "Only models allowed in EU mode projects (data stays inside the EU data path). Every model carries `eu_modus` and, where false, `eu_grund` — the first missing proof (`form: knapp` carries only `eu_modus`)",
+  "type": "boolean"
+}
  2. Changed1 schema field changed
    • removedInput schema / properties / eu
      Removed value: -{
-  "description": "Only models allowed in EU mode projects (data stays inside the EU data path). Every model carries `eu_modus` and, where false, `eu_grund` — the first missing proof (`form: knapp` carries only `eu_modus`)",
-  "type": "boolean"
-}
  3. Changed1 schema field changed
    • addedInput schema / properties / eu
      Added value: +{
+  "description": "Only models allowed in EU mode projects (data stays inside the EU data path). Every model carries `eu_modus` and, where false, `eu_grund` — the first missing proof (`form: knapp` carries only `eu_modus`)",
+  "type": "boolean"
+}
  4. Changed1 schema field changed
    • addedInput schema / additionalProperties
      Added value: +false
  5. 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"
+}
  6. First observed

TDQS

A4.7/5.0
Behavior5/5

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

Annotations only declare readOnlyHint, and the description adds substantial behavioral context: brief caching with `stand` freshness, compact default output, omission of null/false/empty fields, truncation via `form: knapp`, and stub entries for models belonging to multiple classes. It also explains that switchable-audio models appear under the class both with and without sound. This is rich disclosure beyond annotations.

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?

The description is front-loaded with purpose and usage, and every part carries useful information for a complex catalog tool. However, it is a dense paragraph with nested clauses and German field names, making it harder to scan than ideal.

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 full burden of explaining return shape and behavior, and it does so thoroughly: compact vs full output, `klassen`, `stand`, truncation, stubs, null omission, and filter behavior. It is complete enough for an agent to call the tool correctly.

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

Parameters5/5

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

Schema description coverage is 100%, so the schema already documents parameters, but the description adds important semantics beyond it: omitting `klasse` returns a compact catalog, `voll: true` returns every field, `ton: ohne` includes silent and switchable-audio models, and switchable-audio models are listed in two class views. It meaningfully supplements the schema rather than repeating it.

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?

The description states a specific resource and verb: it is the model catalog describing what video/image models can do, including capabilities and pricing. It clearly distinguishes itself as the catalog to read before choosing generation tools, so an agent can tell it apart from siblings like lab_generate or lab_search_catalog.

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?

It explicitly says to read this before choosing a `tool` for lab_generate/lab_animate/lab_propose and to copy ids verbatim, which is strong usage guidance. It also explains how filters answer common questions directly, but it does not name an explicit alternative or when-not-to-use condition, so it falls 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.

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