Skip to main content
Glama
calebn

Podcast MCP

by calebn
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

ripple_delete_text_tool

Ripple-delete the first timeline span matching a transcript text query; audio checks flag harsh or other-speaker cuts and allow recorded overrides.

Instructions

Ripple-delete the first timeline span matching a transcript text query.

The matched speaker's words are the cut; other tracks' speech in the span needs confirmation. The automatic audio checks hold a harsh or other-speaker cut and name the finding; override_audio_checks=true applies it anyway and records the override.

Input Schema

NameRequiredDescriptionDefault
queryYes
project_pathNo
use_inaudible_optNo
override_audio_checksNo

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed5 schema fields changedv0.1.1
    • 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"
    • changedInput schema / required
      Previous value: -[
-  "project_path",
-  "query"
-]New value: +[
+  "query"
+]
  2. First observedv0.1.0

TDQS

B3.4/5.0
Behavior4/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 disclose real behavior: it cuts the matched speaker's words, flags other tracks' speech for confirmation, and the audio checks block a harsh/other-speaker cut unless override_audio_checks=true, which is then recorded. It omits reversibility/undo and permission requirements for a destructive 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?

Three short sentences, front-loaded with the action and scope, then the guardrail behavior. Minor awkwardness in 'The matched speaker's words are the cut,' but no padding.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The output schema exists, so return values need not be described, and the guardrail/override behavior is covered. Still missing parameter meaning for project_path and use_inaudible_opt and any statement of reversibility, which matters for an unannotated destructive tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must explain all four parameters. It explains override_audio_checks well (applies the held cut and records the override) and implies query, but project_path and use_inaudible_opt are never mentioned anywhere, leaving half the parameters undocumented.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb (ripple-delete) and resource (first timeline span matching a transcript text query), with the 'first match' scope narrowing it usefully against siblings like cut_text_match_tool or move_by_text_tool. It stops short of naming the nearest alternative explicitly, so an agent must still infer the boundary.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description conveys the operating condition (matched speaker's words are the cut; other tracks' speech requires confirmation) but never says when to pick this over cut_text_match_tool, cut_words_tool, or ripple_delete_tool. Usage is implied by the query-matching framing rather than stated.

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

Deploy Server

Other Tools