Treza

Create timeline project

create_editor_project

Put the account's own footage, pictures, music or voiceover on a new editable timeline project, in order: video and image clips on the video track, each video's sound on the audio track under it, and music or voiceover on a track of their own from the start. This is how raw footage someone uploaded gets edited by hand-tuned cuts rather than a one-shot assemble_video: create it, read it with get_project, cut and caption it with edit_project, then render_project. Urls come from list_assets (import_media or create_upload_url brings new files in). Up to 30 clips. Needs the pipelines:write scope.

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": {
      "clips": "<clips>"
    },
    "name": "create_editor_project"
  }
}

Input Schema

Name	Required	Description	Default
`name`	No	Project name, e.g. "Lisbon vlog".
`clips`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

AddedNov 3, 2026

TDQS

A4.7/5.0

Behavior5/5

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

Adds substantive behavior beyond the annotations: a hard limit of 30 clips, a required pipelines:write scope, and the precise track-layout/ordering semantics that determine how the timeline is assembled. Annotations already cover the read/write and idempotency profile, so this extra operational context is genuine value.

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 scope, then workflow, then constraints. Dense and mostly waste-free, though the opening sentence runs long and packs ordering details that could be split for readability.

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?

Covers purpose, alternatives, workflow, input sources, clip limit, and required scope — enough for a mutation tool with no output schema. The only gap is it never says what the call returns (presumably a project id for get_project), which an agent would want to chain the next step.

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 only 50% schema description coverage, the description carries real weight: 'in order' explains that clip array order drives track sequencing, and the track-placement rules explain implicitly what kind/position mean. It stops short of explaining atSec defaults or the name field, which are left to the schema.

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?

States a specific verb and resource ('Put ... on a new editable timeline project') and immediately differentiates it from the sibling assemble_video by naming the latter as the one-shot alternative. The track-placement rule (video/image on video track, each video's sound beneath it, music/voiceover on its own track from the start) makes the output concrete.

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?

Gives an explicit workflow chain: create it, read it with get_project, cut/caption with edit_project, then render_project. It also states when-not (one-shot assemble_video) and where inputs come from (list_assets, import_media, create_upload_url), leaving nothing to inference.

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

All Treza 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.