Skip to main content
Glama

select film saved take

native.select_film_saved_take
DestructiveIdempotent

Select a saved Film image, video or clip_audio take with no generation or credits. Inspect its actual media first. Image/video require take_id and both current selected image/video take IDs; selecting a video can restore its source board. For clip_audio supply video_take_id, audio_output_id and expected_audio_output_id (JSON null chooses Original). Audio selection changes only sound attached to that video, preserving picture and upscale. Supply identities from a fresh read; a changed audio choice is refused.

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.select_film_saved_take"
  }
}

Input Schema

NameRequiredDescriptionDefault
work_idYes
argumentsYes
read_skillsYesExact 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_keyYes
publication_proposal_idNoFor native Social scheduling, the exact server-approved publication proposal. This identifier cannot confer approval by itself.
expected_catalog_versionYesFor 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

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.3/5.0
Behavior4/5

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

Beyond the annotations (destructiveHint=true, idempotentHint=true) the description discloses cost ('no generation or credits'), side-effect scope ('selecting a video can restore its source board'), blast radius ('changes only sound attached to that video, preserving picture and upscale') and a failure mode (stale audio identity is refused). It stops short of saying whether a prior selection is lost or undoable, which is the main remaining question for a destructive-flagged tool.

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 action and cost, then per-kind requirements, then the invariant. Dense but each sentence carries information. Minor loss from telegraphic phrasing ('Inspect its actual media first' names no tool) and from cramming three kinds of obligations into two sentences.

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?

A mutation tool with nested arguments, optimistic concurrency, three kinds and an output schema — the description covers the concurrency contract, cost, kind-specific identity requirements and change scope, so an agent can call it correctly. Gaps are small: which tool to inspect with, and whether the previous selection survives.

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 only 50%, but the description compensates by encoding per-kind requirements the schema does not express: take_id plus both expected selected IDs for image/video, and video_take_id + audio_output_id + expected_audio_output_id for clip_audio, with JSON null meaning Original. It is slightly ambiguous about whether both expected selected IDs are mandatory for each kind, and it is silent on work_id/request_key, which is acceptable given they are protocol fields.

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 opens with a specific verb and resource ('Select a saved Film image, video or clip_audio take') and scopes it with 'no generation or credits', which separates it from generate_film_* and from the genads/element/workshop take selectors in the sibling list. An agent can tell what it does and what it does not do without opening the schema.

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 gives real preconditions: inspect the actual media first, and supply identities from a fresh read. It also states a hard exclusion ('a changed audio choice is refused'). What's missing is an explicit pointer to the inspection tool (inspect_asset / native.inspect_source) or an explicit 'use X instead' for non-Film take selection.

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