Skip to main content
Glama
calebn

Podcast MCP

by calebn
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

suggest_handoff_cut_tool

Propose retain-then-snap ripple bounds for podcast narrative handoffs, keeping air on each side and snapping cuts to RMS silence islands.

Instructions

Propose retain-then-snap ripple bounds for a narrative handoff.

Omit track_id and speaker to require quiet across every dialogue lane, including muted lanes. Either selector limits analysis to one lane.

Use when cleaning up a transition, leaving a beat, or punchline-to-pivot — not word timestamps and not preview_inaudible_cut_tool (local snap + ~0.4s absorb). Times are timeline seconds. Keeps about retain_sec of existing air on each keep, snaps onto RMS silence islands (not transcript gaps), and returns use_inaudible_opt: false — lock those bounds on ripple_delete_tool.

Input Schema

NameRequiredDescriptionDefault
hop_msNo
speakerNo
track_idNo
retain_secNo
project_pathNo
keep_left_endYes
min_island_secNo
keep_right_startYes

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed5 schema fields changedv0.1.1
    • 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"
    • removedInput schema / properties / quiet_db
      Removed value: -{
-  "default": -48,
-  "title": "Quiet Db",
-  "type": "number"
-}
    • changedInput schema / required
      Previous value: -[
-  "project_path",
-  "keep_left_end",
-  "keep_right_start"
-]New value: +[
+  "keep_left_end",
+  "keep_right_start"
+]
  2. First observedv0.1.0

TDQS

A4.2/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 so well: it discloses the quiet-across-all-lanes semantics when selectors are omitted, the single-lane scoping when either selector is set, that times are timeline seconds, that snapping is onto RMS silence islands rather than transcript gaps, and that it returns `use_inaudible_opt: false`. It never explicitly states the tool is read-only / does not modify the timeline, which it only implies by telling the agent to apply the bounds elsewhere.

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?

Four short, line-separated sentences, front-loaded with the purpose before the routing exclusions and the output contract. Dense domain vocabulary but no filler; each sentence adds a distinct constraint.

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 complex 8-parameter analysis tool with an output schema (so return values need no explanation), the description covers scope, selector semantics, snapping basis, time units, and the handoff to `ripple_delete_tool`. The only gap is a few tuning parameters, which is minor against the workflow coverage provided.

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

Parameters3/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 compensate and it only partially does: it explains `track_id`/`speaker` as lane selectors and ties `retain_sec` to 'keeps about retain_sec of existing air on each keep', and the two required keep_* bounds are implied by 'retain-then-snap'. `hop_ms`, `min_island_sec`, and `project_path` are never mentioned, leaving three of eight parameters undocumented anywhere.

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 (Propose) and resource (retain-then-snap ripple bounds for a narrative handoff), and explicitly contrasts itself with `preview_inaudible_cut_tool` and word-timestamp tools. The noun phrase 'retain-then-snap ripple bounds' is domain jargon that stays somewhat opaque until the later sentences unpack it, which keeps it short of a clean 5.

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 when-to-use triggers (cleaning up a transition, leaving a beat, punchline-to-pivot) and explicit exclusions ('not word timestamps and not preview_inaudible_cut_tool (local snap + ~0.4s absorb)'). It also names the downstream tool that consumes the output ('lock those bounds on ripple_delete_tool'), so routing is unambiguous.

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