GenFlick

rework film keyframes

native.rework_film_keyframes

DestructiveIdempotent

Repair selected cells of a current Film 3×3 keyframe grid for a local visual defect, through the same durable mask, regenerate and keeper-pixel merge workflow as automatic critique. First inspect the exact selected grid resource in image mode, then supply its resource ID, expected revision, the frame numbers to change (row-major 1–9) and precise visual repair directions for them; every other cell keeps its pixels. For continuity, inspect both adjacent or source grids first and include the other grid under continuity with its own resource, revision, frames and directions; an empty selection keeps every cell on that side. The tool freezes both grids and permits only the selected cells to change. It waits for the saved apply and returns the current resources: inspect them before saying the defect is fixed. Single-image keyframes cannot use this tool. It does not expand the selection or render video.

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

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.

First observedNov 5, 2026

TDQS

A4.7/5.0

Behavior5/5

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

Beyond the annotations (destructive, idempotent, open-world), the description discloses the mechanism: 'through the same durable mask, regenerate and keeper-pixel merge workflow', that both grids are frozen, that 'every other cell keeps its pixels', that the call blocks on the saved apply, and that it returns the current resources. That is substantial behavior not derivable from the hints.

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?

Purpose and prerequisites are front-loaded in the first two sentences, and most detail earns its place. There is some redundancy between 'every other cell keeps its pixels' and 'permits only the selected cells to change', and the long semicolon-chained sentences make it denser than necessary.

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 destructive, revision-checked mutation with nested continuity state and an output schema, the description covers the workflow, freezing semantics, the wait-for-apply behavior, and the exclusions. It stops short of describing failure handling (revision mismatch, rejected instructions) or how partial repair failures surface, which an agent attempting this call would want to know.

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?

With 50% schema coverage, the description carries real weight: it explains frames as 'row-major 1–9', that expected_revision is the grid's revision to be inspected first, that instructions are 'precise visual repair directions', and that the nested continuity object needs its own resource, revision, frames and directions. It does not touch the envelope parameters (work_id, request_key, read_skills, expected_catalog_version), which remain schema-only.

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 opening clause gives a specific verb and resource: 'Repair selected cells of a current Film 3×3 keyframe grid for a local visual defect.' It further bounds scope by stating what the tool will not do ('does not expand the selection or render video') and rules out a whole tool class ('Single-image keyframes cannot use this tool'), which separates it from review/render siblings such as native.review_film_keyframes.

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?

Explicit preconditions are given in order: 'First inspect the exact selected grid resource in image mode, then supply its resource ID, expected revision, the frame numbers...'. It also names the continuity case ('inspect both adjacent or source grids first and include the other grid under continuity'), the degenerate case ('an empty selection keeps every cell on that side'), and a post-condition ('inspect them before saying the defect is fixed').

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?