3D New Era AI

Overview Schema Source Related Servers Discussions Admin

Change or render the video

edit_video

Destructive

Build and render camera path videos by adding keyframes, orbiting, or clearing the path. Set speed and fps, then output a Motion-JPEG .avi file.

Instructions

Change the video camera path, or render it. add {cam? | x?,y?,z?,yaw?,pitch?,fov?, i?} appends a keyframe (missing values from the visitor); delete {i}; clear; orbit {z?,n?} replaces the path with an aerial tour; set {fps?,speed?}; render {path .avi, w?,h?} writes a Motion-JPEG video. cm, degrees, m/s. The path itself is the video tool.

Input Schema

TableJSON Schema

Name	Required	Description
`h`	No	Video height, px
`i`	No	Keyframe index (`delete`, or insert position for `add`)
`n`	No	Keyframes for `orbit`
`w`	No	Video width, px
`x`	No	Keyframe eye position on the plan, cm
`y`	No	Keyframe eye position on the plan, cm (y grows down)
`z`	No	Keyframe eye height, cm
`cam`	No	Stored view index to add as keyframe
`fov`	No	Keyframe horizontal field of view, degrees
`fps`	No	Frames per second of the rendered video
`yaw`	No	Keyframe direction, degrees clockwise on the plan
`path`	No	Output `.avi` for `render`
`pitch`	No	Keyframe tilt, degrees down
`speed`	No	Camera speed m/s
`action`	No	What to do with the camera path

Output Schema

TableJSON Schema

Name	Required	Description	Default
`v`	No
`ok`	No
`ids`	No
`rev`	No
`secs`	No
`text`	No
`bytes`	No
`frames`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed10 schema fields changedv3.0.0Sep 30, 2026

changedInput schema / properties / action / description

Previous value: -"`add`, `delete`, `clear`, `orbit`, `set` or `render`"New value: +"What to do with the camera path"

addedInput schema / properties / action / enum

Added value: +[
+  "add",
+  "delete",
+  "clear",
+  "orbit",
+  "set",
+  "render"
+]

removedOutput schema / properties / bytes / description
```
Removed value: -"action=render: file size"
```
removedOutput schema / properties / frames / description
```
Removed value: -"action=render: frames written"
```
removedOutput schema / properties / ids / description
```
Removed value: -"Ids created or touched"
```
removedOutput schema / properties / ok / description
```
Removed value: -"Always true"
```
removedOutput schema / properties / rev / description
```
Removed value: -"Plan revision"
```
removedOutput schema / properties / secs / description
```
Removed value: -"action=render: length in seconds"
```
removedOutput schema / properties / text / description
```
Removed value: -"The reply as written"
```

removedOutput schema / properties / v / description

Removed value: -"Plan version written to, when there are several"

First observedv0.1.0Sep 24, 2026

TDQS

A4/5.0

Behavior4/5

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

Annotations already declare destructiveHint=true and readOnlyHint=false. The description adds useful action-specific effects: delete removes a keyframe, clear wipes the path, orbit replaces the path with an aerial tour, and render writes a Motion-JPEG file. It does not cover permissions or rate limits, but the destructive semantics are well surfaced.

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 compact and front-loads the core purpose before detailing actions. The semicolon-separated action list is dense but efficient; each clause carries operational meaning with little waste.

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 15-parameter tool with annotations and an output schema, the description covers all six actions, associated parameters, units, and key side effects. It stops short of explaining when to use this tool versus related render/video siblings, but it is otherwise complete enough 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?

Although schema coverage is 100%, the description adds substantial meaning by grouping parameters by action, showing optional combinations like add {cam? | x?,y?,z?,yaw?,pitch?,fov?, i?}, render {path .avi, w?,h?}, and set {fps?,speed?}. It also states units (cm, degrees, m/s), which helps an agent invoke the action correctly beyond the schema descriptions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states that the tool changes or renders the video camera path, and it enumerates the specific path-editing actions (add, delete, clear, orbit, set, render). It does not explicitly differentiate itself from siblings such as video or render_3d, but the core purpose is unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It explains what each action does and which parameters belong to each action, effectively serving as invocation guidance. However, it does not state when to choose this tool over sibling tools like video or render_3d, leaving that comparison implicit.

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