ChatCut

duplicate_project

Duplicate an existing ChatCut project into a new project owned by the signed-in user — the same full copy the editor dashboard's Duplicate action makes (all timelines, tracks, items, captions including word-level edits, speakers, transcripts, and asset references; chat history and markers are not copied).

Use this for safety copies before destructive edits and for project-level variants (language versions, alternate cuts that need separate exports). For variants of a single cut inside the same project, prefer manage_timelines action=duplicate instead.

Only the project owner can duplicate a project. Returns the copy's projectId, editor URL, and live project card. By default the session also re-targets the new copy, but session binding is best-effort: to edit the copy reliably, pass the returned newProjectId as projectId explicitly on subsequent tool calls — an explicit per-call projectId always wins. Pass activate=false to keep the source project targeted.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "duplicate_project"
  }
}

Input Schema

Name	Required	Description
`name`	No	Display name for the copy. Defaults to "[Copy] <source project name>".
`activate`	No	Re-target this external MCP session to the new copy. Defaults to true. Pass false to keep the source project targeted. Either way, prefer passing the returned newProjectId explicitly on subsequent calls that should edit the copy.
`projectId`	No	Project for this call (full ID or unambiguous prefix). Explicit-timeline calls never change the target of later calls; legacy project selection applies otherwise.
`timelineId`	No
`editorBaseUrl`	No	Editor origin/base URL. Defaults to CHATCUT_EDITOR_URL or http://localhost:5173.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedNov 5, 2026

changedInput schema / $schema

Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"

First observedNov 5, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Annotations only declare non-readonly, non-idempotent, non-destructive; the description goes far beyond by listing copied vs omitted content, the owner-only permission gate, the returned artifacts (projectId, editor URL, live project card), and a subtle side effect — default session re-targeting that is best-effort, with the recommendation to pass newProjectId explicitly since a per-call projectId always wins.

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?

Three dense paragraphs, front-loaded with purpose and scope followed by routing and then the returned values/caveats. Almost every clause carries information, though the session-binding caveat is restated in both the description and the activate schema, costing some redundancy.

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 side-effecting duplication tool with no output schema, the description covers what is created, what is omitted, who may call it, what is returned, and how the session target changes afterward — everything an agent needs to invoke it correctly and safely.

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?

Schema coverage is 80%, so the baseline is 3, and the description earns above that by explaining the activate side effect and the precedence of an explicit projectId over session binding. It does not explain the timelineId parameter, which is unintuitive on a project-level duplication tool.

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 + resource ("Duplicate an existing ChatCut project into a new project owned by the signed-in user") and immediately delimits scope by enumerating exactly what is and isn't copied (timelines, captions, speakers, transcripts, asset references vs chat history and markers). It also distinguishes itself from the nearest sibling by naming manage_timelines action=duplicate for the single-cut case.

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 two concrete use cases (safety copies before destructive edits, project-level variants such as language versions and alternate cuts) and explicitly routes the alternative case to manage_timelines action=duplicate. It also states the access precondition (only the project owner can duplicate) and when to pass activate=false.

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

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