Podcast MCP

Overview Schema Source Related Servers Discussions Admin

ripple_delete_tool

Cut a timeline range across every dialogue track and close the gap, with automatic audio-quality checks before the edit is applied.

Instructions

Ripple-delete a timeline range across every dialogue track.

Default inaudible opt absorbs trailing quiet air to ~0.4s before the next word. For punchline-to-pivot / leave-a-beat handoffs, call suggest_handoff_cut_tool first and pass use_inaudible_opt=false so local snap does not pull mid-silence bounds onto speech. track_ids names the tracks whose speech you mean to cut; speech on any other track in the range needs confirmation. Omitted, the cut names no track, so speech on every track needs confirmation (a whole-session time cut). The automatic audio-quality and cut-position checks run first: a cut that lands mid-word, makes an audible join or cuts another track's speech stays unchanged and comes back with the finding. When the user wants that exact cut anyway (or names the position themselves), repeat with override_audio_checks=true; it keeps the bounds as given and records who overrode in History and the edit log.

Input Schema

Name	Required	Description	Default
`end`	Yes
`start`	Yes
`track_ids`	No
`project_path`	No
`use_inaudible_opt`	No
`override_audio_checks`	No

Output Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed6 schema fields changedv0.1.1Oct 19, 2026

addedInput schema / properties / override_audio_checks

Added value: +{
+  "default": false,
+  "title": "Override Audio Checks",
+  "type": "boolean"
+}

addedInput schema / properties / project_path / anyOf

Added value: +[
+  {
+    "type": "string"
+  },
+  {
+    "type": "null"
+  }
+]

addedInput schema / properties / project_path / default
```
Added value: +null
```
removedInput schema / properties / project_path / type
```
Removed value: -"string"
```

addedInput schema / properties / track_ids

Added value: +{
+  "anyOf": [
+    {
+      "items": {
+        "type": "string"
+      },
+      "type": "array"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Track Ids"
+}

changedInput schema / required

Previous value: -[
-  "project_path",
-  "start",
-  "end"
-]New value: +[
+  "start",
+  "end"
+]

First observedv0.1.0Sep 20, 2026

TDQS

A4.7/5.0

Behavior5/5

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

With no annotations, the description carries the full burden and does so well: it discloses the default inaudible-opt absorption, that automatic audio-quality/cut-position checks run first and leave bad cuts unchanged, that other tracks' speech triggers confirmation, and that overrides are recorded in History and the edit log. This is exactly the behavioral context an agent needs before a destructive ripple edit.

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-loads the core action in the first sentence, then layers the option/override guidance in logical order with no filler. Dense and multi-sentence, but each sentence conveys a distinct constraint rather than restating the name or schema.

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?

An output schema exists, so return values needn't be described, and the description fully covers when to use it, override behavior, and confirmation semantics. The only gap is the unexplained project_path parameter, which is minor against the otherwise complete operational picture.

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 0%, so the description must compensate, and it explains the non-obvious parameters in depth (track_ids confirmation semantics, use_inaudible_opt interaction with handoff cuts, override_audio_checks side effects). start/end are self-evident by name, but project_path is never mentioned, leaving one parameter undocumented.

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 (ripple-delete) plus resource and scope (a timeline range across every dialogue track), which cleanly separates it from text-based siblings like ripple_delete_text_tool and from non-ripple cut_time_range_tool/delete_clips_tool. The scope ('every dialogue track') is unambiguous without opening the 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?

Gives explicit routing guidance: call suggest_handoff_cut_tool first for punchline-to-pivot handoffs and pass use_inaudible_opt=false, and repeat with override_audio_checks=true when the user wants the flagged cut anyway. It also states the consequence of omitting track_ids (whole-session cut requiring confirmation on every track).

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

Deploy Server