fpt-mcp

Overview Schema Source Related Servers Discussions Admin

openclip_create

Create a versioned Flame Open Clip (.clip) from published render sequences, providing conformed Source Versions for the Flame timeline; regenerate after each new publish version.

Instructions

Write a versioned Flame Open Clip (.clip) for a shot's published render sequences: one feed per publish version (frame ranges read from disk), current = highest. Gives a conformed Flame timeline Source Versions; regenerate after each new publish version. Generation runs Autodesk's canonical dl_get_media_info per version dir + merges the documents (requires a Flame/mio install on this host — Flame 2027 silently rejects hand-rolled minimal XML, validated in-vivo 2026-08-05).

Task/Step selection (zero silent defaults): pass task_id (or step = Step code/short_name) to build. With neither it returns choice_required with candidate Tasks (+ Task.upstream_tasks suggestion) — confirm with the user, re-call. Never assumes which step feeds the conform.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`params`	Yes

Output Schema

TableJSON Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed3 schema fields changedv1.27.0Aug 19, 2026

addedInput schema / $defs / OpenclipCreateInput / properties / extra_publish_types

Added value: +{
+  "anyOf": [
+    {
+      "items": {
+        "type": "string"
+      },
+      "type": "array"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "Publish TYPES to splice in beside the Task-selected versions, matched on the Shot regardless of Task (e.g. ['Flame Render']). Chat 99: Flame's own tk-flame batch-render integration publishes the comp as 'Flame Render' with NO Task — its context comes from the .batch path, whose template carries no Step token — so no step/task selector can reach it and the conformed clip never learns the comp exists. Each type becomes its own version group appended AFTER the task-selected ones, so it lands on top and becomes current. The uid token is read from the publish code (<Shot>_<TOKEN>_v<version> -> 'CMP_v001'), falling back to the type name uppercased. Explicit by design: the tool still never guesses which publishes feed a conform.",
+  "title": "Extra Publish Types"
+}

addedInput schema / $defs / OpenclipCreateInput / properties / keep_source_current

Added value: +{
+  "default": false,
+  "description": "Mark the FIRST (source) version current instead of the newest. Chat 99, measured in-vivo: Flame reads the very same .clip as start_frame=1001 when the light version is current and as start_frame=0 (spanning 1101 frames) when the comp version is — so with the comp current every 'Update Sources' replace anchored the conformed segment at 00:00:00:00 and lost its cut. Aligning the feeds' timecode, rate, sampleRate and TimecodeSource did NOT change that. Keeping the source current sidesteps it without writing to the timeline: the comp version is still in the clip and the operator flips to it natively, which is the intended gesture anyway.",
+  "title": "Keep Source Current",
+  "type": "boolean"
+}

addedInput schema / $defs / OpenclipCreateInput / properties / steps

Added value: +{
+  "anyOf": [
+    {
+      "items": {
+        "type": "string"
+      },
+      "type": "array"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "MULTI-STEP aggregation (Chat 98 comp architecture): splice publishes from SEVERAL Steps into ONE clip, in list order (e.g. ['Light', 'Comp'] → the conform timeline sees the LGT render and every comp version through the same open clip, flipping natively). Version uids are disambiguated with the step string uppercased ('LIGHT_v003', 'COMP_v001'); current = the newest version of the LAST listed step that has publishes. A listed step with no publishes is skipped and reported, never an error — the clip is valid before the first comp render exists. Takes precedence over 'step'/'task_id'.",
+  "title": "Steps"
+}

Changed2 schema fields changedv1.25.0Aug 11, 2026

addedInput schema / $defs / OpenclipCreateInput / properties / step

Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "Pipeline Step selector: matches the publish Task's Step by code OR short_name (e.g. 'Light' / 'LGT'). Ignored when task_id is given. When BOTH are omitted the tool never builds: it returns a choice_required listing of the shot's candidate Tasks (publish counts + a dependency-based suggestion when the task graph provides one) for the caller to confirm.",
+  "title": "Step"
+}

addedInput schema / $defs / OpenclipCreateInput / properties / task_id

Added value: +{
+  "anyOf": [
+    {
+      "type": "integer"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "Explicit ShotGrid Task id whose publishes populate the clip. Strongest selector — takes precedence over 'step'.",
+  "title": "Task Id"
+}

Addedv1.24.0Aug 7, 2026

TDQS

A4.9/5.0

Behavior5/5

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

Even without annotations, the description fully discloses its behavior: it requires a Flame/mio install, warns about Flame 2027 rejecting hand-rolled XML, explains that deprecated parameters are ignored, explicitly states the tool never builds when task/step are omitted, and describes multi-step aggregation quirks (e.g., skipping empty steps, precedence rules). It even notes the keep_source_current workaround for a Flame behavior it measured in-vivo. This goes far beyond what annotations would typically provide.

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?

The description is dense and front-loaded, starting with the core purpose and then adding nuance. However, it is long and includes inline anecdotal details (Chat 98/99, in-vivo) that, while valuable, could be slightly condensed without losing meaning. Still, every sentence earns its place, covering critical non-obvious constraints and edge cases.

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?

Given the tool's complexity (multiple selection modes, aggregation, deprecated fields, external dependencies, Flame version quirks) and the lack of annotations, the description is remarkably complete. It covers the prerequisites (Flame/mio install), the return behavior (choice_required), the failure modes (skipped steps, Flame rejection), and even the rationale for defaults. The output schema exists, so return-value details are not needed here. This is exceptionally thorough.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0% per the context signals, though the schema descriptions are actually rich internally. However, the tool description adds a lot of semantic meaning to parameters: it explains the interplay of task_id/step/steps, precedence rules, the deprecated fps and clip_name, and the extra_publish_types' purpose. It clarifies what step matching does and the terminal behavior for omitted selectors. This far exceeds what the schema alone provides, especially since the description uses these parameters in orchestration narratives (Chat 98/99, in-vivo observations).

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 a specific verb and resource: 'Write a versioned Flame Open Clip (.clip) for a shot's published render sequences'. It clearly distinguishes this from siblings by framing it as a generation tool for Flame conform, not a generic SG/find/create/update tool. It also specifies the output is a versioned clip with one feed per publish version, which is a unique purpose.

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?

The description explicitly states 'Task/Step selection (zero silent defaults): pass task_id (or step = Step code/short_name) to build. With neither it returns choice_required... confirm with the user, re-call. Never assumes which step feeds the conform.' This provides explicit when-to-use versus alternatives: it explains the tool refuses to guess and requires the caller to select a task/step, and even offers a suggestion for choosing among candidates. It also states the necessity to regenerate after each new publish version.

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

Deploy Server