Vidova

Split an image into layers

extract_layers

Split an image into its separate pieces, as transparent layers: each layer is a new PNG asset that holds some of the picture's objects, cut out with their own edges, and transparent everywhere else. Stacked bottom to top they make the picture again. Use it to take a generated collage, poster or scene apart, so each piece can be placed, moved and animated on its own: a paper cut-out that drops in, a headline strip that slides, a background that stays still. The answer lists the layers bottom layer first. Look at each with read_asset before you place it: the model decides what goes in which layer. To cut one object or a logo out of its background, remove_background is enough. It answers at once with a Job ID and the media is made in the background: start every generation you need, keep working, then call wait_for_jobs with all their Job IDs to get each Asset ID for patch_film. Uses about 24 credits a layer: 4 layers use 97 credits.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "assetId": "<assetId>",
      "layers": "<layers>",
      "caption": "<caption>",
      "projectId": "<projectId>"
    },
    "name": "extract_layers"
  }
}

Input Schema

Name	Required	Description
`layers`	Yes	How many layers to split it into, 2 to 8. null for 4. More layers separate smaller pieces.
`assetId`	Yes	The ready image asset to split into layers. Use the IDs search_assets gives.
`caption`	Yes	A short description of the whole picture, or null to let the model describe it. It does not choose what goes in each layer.
`projectId`	Yes	The project this call runs on without changing the open project. null (or leaving it out) uses the open project. wait_for_jobs takes the projectId of the calls that started the jobs.

Schema Changelog

Changes observed during successful MCP inspections.

AddedNov 7, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Beyond the annotations (readOnlyHint=false, destructiveHint=false, openWorldHint=true), the description discloses the asynchronous contract (returns a Job ID immediately, media rendered in the background), the ordering of results (bottom layer first), the non-determinism (the model decides layer contents), and the cost model (~24 credits per layer, 97 for 4). These are exactly the traits an agent cannot infer from the structured fields.

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 with the core operation and its result before branching into use cases, exclusions, follow-up workflow, and pricing. Dense but nearly every sentence carries operational value; the animation examples (paper cut-out, headline strip, background) are slightly illustrative padding but do clarify the intended output.

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 4-parameter, annotation-light, no-output-schema mutation tool, the description covers everything an agent needs: async job semantics, result ordering, how to inspect and consume layers, the routing to remove_background, and cost. Nothing material 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 coverage is 100%, so the baseline is 3; the description adds real meaning by tying the `layers` parameter to cost ("about 24 credits a layer: 4 layers use 97 credits") and clarifying that `caption` does not control layer composition ("It does not choose what goes in each layer"). It leaves `assetId` sourcing and `projectId` forwarding to the schema, which already covers them adequately.

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 specific verb and resource ("split an image into its separate pieces, as transparent layers") and describes what the output actually is: new PNG assets with cut-out edges and transparency that re-stack into the original. It also names the sibling it is not (remove_background) for the single-object case, so the agent can distinguish it without opening any schema.

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?

Gives an explicit use case (taking a generated collage, poster or scene apart for placement/animation) and an explicit exclusion with the alternative to use instead ("To cut one object or a logo out of its background, remove_background is enough"). It also prescribes the follow-up workflow: read_asset each layer before placing, then wait_for_jobs with the Job IDs to get Asset IDs for patch_film.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All Vidova tools Inspect

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.