GenFlick

apply film studio actions

native.apply_film_studio_actions

DestructiveIdempotent

Apply Film actions in order with the supplied authoring revision. One call carries a whole pass, up to 128 actions: a later action can use the cast, sets, props and scenes an earlier one creates, so a build's elements, scenes with their shots and element images go in one call. Each action names only the fields it changes. Default completion saves text without generation; requested_media_applied requires creator generation intent. The saved receipt verifies authoring. The common payloads are given in full here; read_film_studio_action_contract gives any other action's fields. No overview or craft-guide read is required. Wait only for returned pending media. Every document action (find_and_replace_in_document, apply_document_edits, replace_document_body) names its document with document_id (preferred, from the documents read) or document_title; a call with neither is rejected. For example {"type":"find_and_replace_in_document","document_id":"","find":"old","replace":"new"}.

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": {
      "work_id": "<work_id>",
      "arguments": "<arguments>",
      "expected_catalog_version": "<expected_catalog_version>",
      "read_skills": "<read_skills>",
      "request_key": "<request_key>"
    },
    "name": "native.apply_film_studio_actions"
  }
}

Input Schema

Name	Required	Description
`work_id`	Yes
`arguments`	Yes
`read_skills`	Yes	Exact required native skills and their dependencies, copied from the accepted session bootstrap's skills array. Include only entries in that array. General mcp.* guides and native.{studio}.instructions are guidance, not native skill proofs.
`request_key`	Yes
`publication_proposal_id`	No	For native Social scheduling, the exact server-approved publication proposal. This identifier cannot confer approval by itself.
`expected_catalog_version`	Yes	For a new session, read a studios/{studio}/native/{pack} child toolset and copy invocation.catalog_version from a native tool descriptor. Do not use the top-level library version. For calls in an existing session, use that session proposal's catalog_version.

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedNov 5, 2026

addedInput schema / properties / arguments / properties / actions / description

Added value: +"For a single still, create_scenes needs clear_existing:false and a scenes list. Each scene supplies a stable scene_key, scene_title and a clips list. Each clip supplies title, board_prompt and video_prompt; use keyframe_format single for a single still. Both prompt fields are required even for a still; saving video_prompt does not generate video. Never put a shot title or prompt directly on the create_scenes action."

First observedNov 5, 2026

TDQS

A4.1/5.0

Behavior4/5

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

Annotations already declare destructiveHint=true, idempotentHint=true and openWorldHint=true, but the description adds real behavioral context beyond them: strict in-order execution, cross-action dependency resolution within a pass, partial field updates ('each action names only the fields it changes'), no implicit media generation on default completion, and a saved receipt that verifies authoring. Gaps remain around partial-failure/rollback semantics for a destructive batch and around how a rejected document action affects the rest of the pass.

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 contract in the first two sentences, and the generation/completion caveat follows early. It is dense and somewhat sprawling thereafter, and the document-naming rule is restated in the description and again verbatim in several schema descriptions, which is redundant. Little is pure waste, but the middle section could be tightened.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a very high-complexity batched mutation tool, the description covers ordering, size limits, dependency resolution, completion modes, waiting behavior, and where to find the action contract. An output schema exists, so return values need not be explained, and it still mentions the verification receipt. It omits atomicity/partial-application behavior, which matters given destructiveHint=true and a 128-action pass.

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 only 50%, so the description must carry extra weight, and it does for the two most complex parameters: the actions array (ordering, 128 cap, 'fields it changes' semantics, document_id vs document_title with rejection when neither is given) and completion (prompt_applied vs requested_media_applied). However, it adds nothing for request_key (which has no schema description at all despite idempotentHint=true) and leaves expected_catalog_version and read_skills entirely to the schema, so the compensation is partial.

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?

Names a specific verb and resource ('Apply Film actions in order') and immediately qualifies the scope: one call carries a whole pass of up to 128 actions, executed in order with cross-action dependencies. It also separates this tool from the companion read tool by stating that 'read_film_studio_action_contract gives any other action's fields,' so an agent can tell which tool does the writing and which does the lookup.

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?

Gives concrete usage conditions: batch a whole build into one call because later actions can reference earlier-created cast, sets, props and scenes; default completion saves text without generation, while requested_media_applied requires explicit creator generation intent; 'No overview or craft-guide read is required'; and 'Wait only for returned pending media.' It also states a hard rejection rule for document actions. It stops short of saying when NOT to use this batched tool versus single-purpose siblings such as native.apply_document_edits or native.apply_canvas_actions.

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

All GenFlick 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.

Resources

Need Help?