ChatCut

read_script

Script is the editing surface for transcript-based editing: use it whenever the spoken words or their meaning decide what plays, is removed, kept, or reordered. That includes deleting spoken words, fillers, or verbal habits (e.g. [s1] 过去~~呢~~一个月); cutting or compressing a specific pause; removing failed retakes or duplicates; clips, highlights, short or multiple versions ("keep the part about pricing", "make a 30s version"); and pulling library transcript onto the timeline.

Not for: fixing ASR text (manage_transcript action fix); B-roll, MG, overlays, effects, transitions, or positions (edit_item); mechanical whole-track filler and pause cleanup (clean_script); timestamps for placing objects (find_transcript); read-only transcript excerpts or frames (inspect_asset). Do not use find_transcript + split_item / edit_item as a shortcut for a transcript-based cut.

This tool materializes timeline.md (the current cut of one speech track) and library/<filename>.md (full source transcripts). Workspace surfaces write them to disk: read and edit them with Read / Edit / Write (Codex plugin sessions: read_workspace_file / edit_workspace_file), then call apply_script(). External surfaces without a workspace get them returned inline: edit the text yourself and pass the full content back via apply_script({timelineMd}). The timelineMd parameter of apply_script defines the file format and edit syntax.

Loop: read_script → edit timeline.md (related replacements in one Edit; fix validation diagnostics in place) → apply_script → the file is re-materialized clean. Call read_script again after a stale-script error, to change track scope or showSilence; add refreshCache when the source transcript changed. Middle deletions or moves split clips; that is expected, so cover visible jump cuts afterwards if needed.

In chat, describe edits by their spoken content, never by [sN], [cN], [gap], or other internal addresses the user cannot see.

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

Input Schema

Name	Required	Description
`track`	No	Optional timeline track alias/id. Omit for normal use so read_script picks the default speech track. Do not pass A1 just because the content has audio; use A1 only if preview_timeline shows an actual audio track alias.
`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
`showSilence`	No	Opt-in: include `[silence=Ns]` markers in the materialized files for precise manual pause edits. Default false. Hidden silence markers do not prevent batch pause cleanup: use `clean_script` for whole-track or bulk silence compression/restoration. Turn this on only when you need to inspect or manually adjust specific pause durations.
`refreshCache`	No	Bypass and replace the task-local transcript cache before materializing Script. Use after transcript data changed or when explicitly checking fresh ASR data.

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.6/5.0

Behavior4/5

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

Annotations only say readOnlyHint=false, destructiveHint=false, so the description carries the real burden and does: it discloses that files are written to disk on workspace surfaces vs returned inline elsewhere, the read → edit → `apply_script` loop, the stale-script error recovery path, and that middle deletions/moves split clips. The one gap is that the exact file contents/format are deferred entirely to `apply_script`'s `timelineMd`, so the agent must trust an unstated format.

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?

Purpose is front-loaded in the first sentence and the tool's role, exclusions, mechanics, loop, and error handling follow in a logical order. It is dense rather than padded, but the closing chat-etiquette instruction and some of the loop restatement sit close to the edge of what a tool definition needs to say.

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 5-parameter tool with no output schema, this is unusually complete: it explains the two files produced, both delivery surfaces (disk vs inline return), the round-trip with `apply_script`, the re-read triggers (stale script, track scope, `showSilence`, `refreshCache`), and the expected clip-splitting consequence. An agent could run this workflow end-to-end from the description alone.

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 most parameters are self-documented; the description still adds genuine decision value beyond the schema by explaining when to opt into `showSilence` (manual pause inspection only, not bulk cleanup, which is `clean_script`) and when to use `refreshCache` (source transcript changed). `timelineId` receives no explanation anywhere, keeping it below a 5.

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 description states a concrete action: materializing `timeline.md` (current cut of one speech track) and `library/<filename>.md` (full source transcripts), and the first sentence pins down that this is the editing surface for transcript-based cuts. It is immediately distinguishable from every relevant sibling, with an explicit 'Not for' list naming `manage_transcript`, `edit_item`, `clean_script`, `find_transcript`, and `inspect_asset`.

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?

Explicit when-to-use cases are enumerated (deleting fillers, compressing pauses, removing retakes, making highlights/versions, pulling library transcript to the timeline) and paired with a when-not list that names the alternative tool for each excluded case. It even forbids a specific anti-pattern (`find_transcript` + `split_item` as a shortcut for a transcript cut).

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.