Podcast MCP

Overview Schema Source Related Servers Discussions Admin

strip_silence_tool

Remove silence from podcast tracks by rebuilding audio from detected speech islands between quiet gaps, using the track's voice floor to identify silence.

Instructions

Rebuild a track from speech islands between detected silences.

Silence is audio under the track's own audibility floor (its voice floor) plus over_voice_floor_db. A track whose voice does not stand out of its room has no silence to strip, whatever over_voice_floor_db is.

use_inaudible_opt is accepted for API compatibility but ignored.

Input Schema

Name	Required	Description	Default
`speaker`	No
`track_id`	No
`project_path`	No
`min_duration_sec`	No
`use_inaudible_opt`	No
`over_voice_floor_db`	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 / over_voice_floor_db

Added value: +{
+  "default": 0,
+  "title": "Over Voice Floor Db",
+  "type": "number"
+}

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 / threshold_db

Removed value: -{
-  "default": -40,
-  "title": "Threshold Db",
-  "type": "number"
-}

removedInput schema / required
```
Removed value: -[
-  "project_path"
-]
```

First observedv0.1.0Sep 20, 2026

TDQS

B3/5.0

Behavior3/5

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

With no annotations, the description carries the full burden, and it does disclose real behavior: the definition of silence (voice floor plus over_voice_floor_db) and the important fact that use_inaudible_opt is accepted but ignored. It stops short of the safety profile though — nothing about whether the rebuild is destructive, reversible, or how it interacts with the edit/undo history (history_undo_tool exists as a sibling).

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-loaded with the core action in the first sentence, followed by definitions that earn their place. The second paragraph is dense but necessary to define 'silence,' and the ignored-parameter note is high value. Slightly more prose than needed for the no-op caveat.

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?

An output schema exists, so return values need not be explained. For a 6-parameter, zero-annotation mutation tool, the description covers the algorithm's semantics adequately but omits invocation guidance and most parameter meanings, leaving the agent short of what it needs to call this correctly.

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 coverage is 0% across 6 parameters, so the description must compensate. It meaningfully explains over_voice_floor_db and flags use_inaudible_opt as a no-op, but speaker, track_id, project_path, and especially min_duration_sec (central to what counts as a speech island) are left entirely to the reader.

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 and resource plus the mechanism: 'Rebuild a track from speech islands between detected silences.' An agent knows exactly what operation this is. It does not, however, distinguish itself from near siblings like preview_inaudible_cut_tool or cut_time_range_tool, which is what a 5 would require.

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

Usage Guidelines2/5

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

There is no explicit when-to-use, when-not-to-use, or named alternative. The remark that a track whose voice doesn't stand out 'has no silence to strip' is a conditional about the algorithm, not guidance on choosing this tool over the other cut/cleanup siblings. The agent must infer the invocation context entirely.

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

Deploy Server