Skip to main content
Glama

Generate Cut-Out Layer Element

lab_layers

Produce ONE element on a transparent background: generated, then cut out and stored as an alpha PNG in the project's gallery. This is the counter-move to the one-shot lottery — cast, props and foreground pieces are made SEPARATELY, arranged as a set afterwards and only then unified, so a wrong hand or a wrong lamp is re-made alone instead of re-rolling the whole frame. The element is deliberately optics-neutral: no lens or camera suffix travels with it, because the look is decided later on the finished comp and every layer is meant to inherit the same focal length and bokeh. ASYNCHRONOUS: the row comes back with status pending and image_url null; poll lab_job_status (type 'image') with its id until the url is populated — that url IS the cut-out. Costs credits when called without get_cost.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
promptYesWhat the element shows — the OBJECT or the PERSON, not the scene around them. The backend appends an isolation clause (single subject, plain seamless background, even light) so the cut-out has a clean edge; describing a set as well fights that clause and produces an element that cannot be freed.
get_costNoPreflight: return the price in credits and your balance WITHOUT generating and without spending anything. There is no model to pick on this path — the cut-out runs on the house image model and is billed at the plain image rate, so lab_list_models has no entry that would change this number; it comes from the same cost endpoint as everywhere else.
metadataNoFree-form JSON stored alongside the element (e.g. { note, parent_id }). Merged into the row's metadata next to the fields the pipeline sets itself (kind, layer_type, status) — not interpreted.
scene_refNoScene label (e.g. 'SZ 04'). Stored on the row, so the element can be matched back to a shot list and reviewed per scene with lab_review_queue. Omit it and the element is an orphan in the gallery.
layer_typeNoWhich kind of element this is — it picks the isolation clause: 'cast' full-body person, 'prop' single object, 'foreground' a foreground piece, 'background' a wide backdrop plate WITHOUT people, 'crowd' one background performer head to feet. 'stage' is accepted by the backend but has no clause of its own and falls back to the generic one. Omit for the backend default ('prop').
project_idYesProject id (from lab_list_projects) — positive integer as string. Travels in the URL; the element is filed in this project's gallery.

Schema Changelog

Changes observed during successful MCP inspections.

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

TDQS

A4.7/5.0
Behavior5/5

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

Annotations only say it is a non-read-only, non-destructive tool. The description goes far beyond that: it reveals the async behavior (row returns status pending and image_url null), the credit cost when called without get_cost, the deliberate optics-neutrality (no lens/camera suffix), and the isolation clause appended to the prompt. That is rich context the annotations do not carry.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with the core operation, then the rationale for separate layers, then the async contract, then cost. Every sentence adds a distinct behavioral fact (transparency background, per-element re-make, optics-neutral, pending/null, poll url, credit cost). No 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?

Despite no output schema, the description fully covers the return contract (pending row, null image_url, populated url is the cut-out), the cost behavior, the async polling path, and the purpose of scene_ref/layer_type in routing to isola clauses. Nothing an agent needs to invoke and follow through 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 coverage is already 100%, so the schema documents every parameter in detail. The description does emphasize the key constraint (prompt is the object/person, not the scene; describing a set fights the isolation clause) and mentions layer_type selection, but most parameter details are already in the schema — baseline 3 is appropriate.

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 the exact artifact (ONE element on a transparent background, generated, cut out, stored as an alpha PNG in the project gallery) and distinguishes the counter-move from the one-shot lottery — cast, props and foreground pieces are made separately. It also clarifies that this is the per-element generator, not the whole-frame generator like lab_generate.

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 tells the agent when to use this vs. the alternative (re-rolling the whole frame), and gives operational routing for the async path: poll lab_job_status (type 'image') with its id until the url is populated. It also notes that get_cost must be set to avoid spending credits.

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