Skip to main content
Glama
Sign In

Vixdeo — Tu Productor IA

by com.vixdeo
OverviewDiscussionsAdmin

Stage a free edit op

stage_op

Stages ONE free edit op on a project — deterministic, no provider is called — into the project's conversation draft: the SAME op the human director runs from a panel or the chat (agent and human edits converge on ONE op-log). The draft becomes a new version when it is committed. Only the free ops run here: the paid re-authoring ops and the creation fields have their own tools (invocableVia in the op catalogue names the tool of each op). Ops:

  • assign_material_to_shot: Puts a piece of the person's own library material (its asset_id: a photo or a video they uploaded) on one shot of a scene, by default the base shot that is the scene's visual; the edit mounts it as is, with nothing bought or searched. Deterministic, $0. Args: scene_index, asset_id (the assetId of the person's own material in the piece), shot_index? (0-based; default the base shot, which is the scene's visual), shows? (what the material shows, in English; the shot's brief only when the scene has no shot list yet), source_start_sec? (second of the video the shot enters from); only on an ai_image, ai_video or archive scene.

  • assign_narration_to_scene: Sets a segment (from_sec-to_sec) of the person's own recording (its asset_id: an audio file, or the sound of a video they uploaded) as the VOICE of one scene; with with_picture that video is also the scene's picture, tied to its voice. The voice is cut from the recording at the next build, not synthesized, and a voice regeneration keeps it. Deterministic, $0. Args: scene_index, asset_id (the assetId of the person's own recording in the piece: an audio file, or a video whose sound is the voice), from_sec, to_sec (the segment, in seconds from the start of the recording), with_picture? (video only: the same segment is also the scene's picture, tied to its voice; only on an ai_image, ai_video or archive scene). The voice is cut from the recording at the next build, not synthesized.

  • remove_narration_from_scene: Returns one scene to the cast voice: the person's own recording it spoke with is taken away. Deterministic, $0. Args: scene_index (the scene goes back to the cast voice).

  • replan_scenes: Reorder the scenes (a permutation of indexes). Deterministic, $0. Args: order=[int...].

  • set_piece_fields: Set PIECE-level fields (production_score: silence_plan, music_intent, narrative_arc…), validated by the schema. Deterministic, $0. Args: fields (partial production_score: silence_plan, music_intent, narrative_arc, expected_total_duration_sec…; lists replace).

  • set_scene_fields: Set concrete fields of one scene (narration, duration, silences, infographic data…), validated by the schema. Deterministic, $0. Args: scene_index, fields (partial scene object: narrator_text, direction_notes, pre_silence_sec, pause_after_sec, visual.duration_target_sec, visual.prompt, infographic.data, kinetic_caption…; nested dicts merge by key, null deletes; validated by the VBP schema).

  • set_title: Sets the piece's TITLE (the name it is saved and published under); once committed, the choice is sealed and nothing overwrites it. Deterministic, $0. Args: title (the new title of the piece: one line, in the piece's language, at most 140 characters).

  • set_visual: Set a scene's visual type and/or visual prompt. Deterministic, $0. Args: scene_index, visual_type?, visual_prompt?.

  • swap_voice: Change the voice (semantic attributes) of one scene or all of them. Deterministic, $0. Args: voice_spec={...} (semantic attributes only: timbre, cadence, accent, language, apparent_gender, voice_style — NOT a voice id: the concrete voice is a piece-level decision made when the piece is created; a scene has no voice pin of its own, for the human either), scene_index?. The result carries the coherence report: a hasBlocking draft can still be committed with force=true. While an authoring turn of the same project is in flight the draft is not touched (authoring-in-progress). Requires the write scope. $0.

Input Schema

NameRequiredDescriptionDefault
opYes
argsYesOp arguments (see description).
project_idYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / op / enum
      Previous value: -[
-  "assign_material_to_shot",
-  "assign_narration_to_scene",
-  "remove_narration_from_scene",
-  "replan_scenes",
-  "set_piece_fields",
-  "set_scene_fields",
-  "set_visual",
-  "swap_voice"
-]New value: +[
+  "assign_material_to_shot",
+  "assign_narration_to_scene",
+  "remove_narration_from_scene",
+  "replan_scenes",
+  "set_piece_fields",
+  "set_scene_fields",
+  "set_title",
+  "set_visual",
+  "swap_voice"
+]
  2. Changed1 schema field changed
    • changedInput schema / properties / op / enum
      Previous value: -[
-  "replan_scenes",
-  "set_piece_fields",
-  "set_scene_fields",
-  "set_visual",
-  "swap_voice"
-]New value: +[
+  "assign_material_to_shot",
+  "assign_narration_to_scene",
+  "remove_narration_from_scene",
+  "replan_scenes",
+  "set_piece_fields",
+  "set_scene_fields",
+  "set_visual",
+  "swap_voice"
+]
  3. Added

TDQS

A4.7/5.0
Behavior5/5

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

Annotations only say it is a non-read-only, non-destructive, non-idempotent closed operation; the description adds substantial beyond that: no provider is called ($0), edits land in a draft that only becomes a version on commit, the result carries a coherence report where `hasBlocking` can be overridden with force=true, writes are skipped while an authoring turn is in flight, and `write` scope is required. Per-op behavior is also disclosed (e.g. set_title is sealed once committed, narration is cut from the recording rather than synthesized and survives voice regeneration).

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 summary paragraph is front-loaded and the per-op bullet list is a genuinely useful structure for a polymorphic tool. It is long, with some redundancy — 'Deterministic, $0' repeats on every bullet and the 'cut from the recording at the next build, not synthesized' sentence appears twice within assign_narration_to_scene.

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 nine-variant polymorphic tool with a 33%-covered schema and no output schema, the definition covers purpose, per-op arguments, side effects and reversibility, blocking conditions, auth scope, and what the result carries (the coherence report). Nothing material is missing for correct invocation.

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 coverage is only 33% with a free-form `args` object, so the description must carry the load, and it does: each enum value of `op` gets a documented arg list with types, defaults, optionality and constraints (e.g. shot_index 0-based defaulting to the base shot, from_sec/to_sec segment semantics, with_picture being video-only and valid only on ai_image/ai_video/archive scenes, nested dicts merging and null deleting in set_scene_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?

Opens with a specific verb and resource plus scope: 'Stages ONE free edit op on a project — deterministic, no provider is called — into the project's conversation draft.' It further distinguishes itself from the paid re-authoring ops and creation-field tools, so an agent can separate it from author_op/run_op without opening schemas.

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?

Clearly states the boundary: only free ops go here, paid re-authoring ops and creation fields have their own tools, and `invocableVia` in the catalogue maps each op to its tool. It also names the commit step that turns a draft into a version and the `authoring-in-progress` no-op condition. Lacks explicit named siblings (e.g. run_op, author_op, commit) so the routing cue is conceptual rather than literal.

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

All Vixdeo — Tu Productor IA toolsInspect
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