ChatCut

clean_script

Mechanical first-pass cleanup of talking-head speech already on the timeline: removes a fixed filler list and batch-compresses or restores pauses. It writes the timeline immediately and has no preview. Both run by default; only picks one. Runs incrementally and preserves item decoration and earlier Script edits.

Fillers removed: EN um / uh / er / ah; ZH 呃 / 额. Not removed: 呢 / 啊 / 嗯 / mm / hmm, stutters, repeats, retakes. When the user wants one of those gone, strike it in Script, e.g. [s1] 过去~~呢~~一个月.

Pauses: translate the request into the silence rule: "tighter breaths" → default compress:250; "only pauses over 0.8s" → longSilence: 800; "keep at least 0.5s" → restore:500. Whole-track cleanup also trims padding before the first and after the last spoken word, including a recording tail. Silence markers do not need to be visible first.

If the user asks to preview the whole edit before it is applied, do not call clean_script. Call read_script({showSilence:true}), stage the filler strikes, semantic edits, and pause rewrites [silence=Xs→Ys] (Unicode →) together in timeline.md, then apply_script({preview:true}). A struck filler joins the pauses on both sides, so a 250ms cap is their combined total. When the preview succeeds and the request already authorizes applying, apply without preview; if the user asked only for a preview, stop.

Not for: specific word deletions, choosing retakes, duplicate sentences, or any edit that depends on meaning (use Script), and ASR text fixes (manage_transcript action fix). After cleanup, continue from the bounded result; read Script only when semantic editing starts.

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": "clean_script"
  }
}

Input Schema

Name	Required	Description
`only`	No	`fillers`, `silence`, or both as `fillers,silence`. Default runs both.
`track`	No	Track alias (`V1`, `A1`, …) to scope to one track. Omit to clean the first timeline track containing transcribed media.
`silence`	No	Pause rule. Default compression is `"compress:250"`, which shortens pauses longer than 250ms to 250ms. Other forms: `"restore:500"` makes short pauses longer up to 500ms only when that pause was already that long in the original recording; `"normalize:500"` moves every editable pause toward 500ms; `"range:300-800"` keeps pauses between 300ms and 800ms; `"normalize:500,range:300-800"` changes only pauses whose current duration is 300–800ms, setting them toward 500ms while leaving shorter and longer pauses alone. Any rule that makes a pause longer never invents new silence; it only recovers pause time that already existed at that exact spot. Legacy syntax also works: `"max:400"`, `"min:500"`, `"500"`, `"min:300,max:800"`. To skip silence entirely, pass `only="fillers"`.
`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
`longSilence`	No	Long-pause-only mode: process pauses at least this many ms long and shorten them to the default 250ms. Omit for normal compress:250 behavior. Ignored when `silence` is set.

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 the safety flags; the description adds the traits that actually matter for this mutation: it 'writes the timeline immediately and has no preview', runs incrementally, and preserves item decoration and earlier Script edits. It further discloses the exact filler list, what is deliberately not removed, and how silence rules behave; the immediate-write/no-preview note is consistent with destructiveHint=false because the edit is incremental and preserves prior work.

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 long, but it is front-loaded with purpose and immediate-write behavior, then broken into scannable blocks for fillers, pauses, preview escalation, and exclusions. A few passages, such as the combined filler-plus-pause total note, are dense, yet nearly every sentence carries operative information an agent needs.

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?

This is a complex, default-writing, multi-mode mutation tool with no output schema and only safety annotations, and the description covers what changes, what is preserved, what the defaults are, when to avoid the tool, and how to resume afterward ('continue from the bounded result'). Nothing essential for a correct first call is missing.

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 already 83% and the silence parameter is documented in depth there, so the schema carries most of the burden. The description still adds real value by mapping user phrasing to rules ('tighter breaths' to compress:250, 'only pauses over 0.8s' to longSilence: 800, 'keep at least 0.5s' to restore:500) and by clarifying that both passes run by default unless only is set.

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 first sentence gives a specific verb and resource: 'Mechanical first-pass cleanup of talking-head speech already on the timeline: removes a fixed filler list and batch-compresses or restores pauses.' It also scopes itself against semantic editing and transcript fixing, so an agent can tell it apart from read_script, apply_script, and manage_transcript without opening any schema.

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?

It states explicitly what it is not for ('specific word deletions, choosing retakes, duplicate sentences, or any edit that depends on meaning (use Script), and ASR text fixes (manage_transcript action fix)') and gives an alternative path. It also gives a decisive escalation rule: if the user asks for a full preview, do not call clean_script but use read_script then apply_script({preview:true}).

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.