Podcast MCP

by calebn

Overview Schema Source Related Servers Discussions Admin

Python

Local

propose_edits

Proposes filler and pause tighten edits for review, returning JSON with edits and skip counts; does not apply them.

Instructions

Propose filler/pause tighten edits for review (does not apply them).

Returns a JSON object {operation, edits, skip_counts, summary} (not a bare array — breaking vs older list-of-decisions clients). operation is propose_edits. Each edit also carries label (plain words, e.g. "Laugh") and suggested_action (cut / shorten / lower / leave) from one table (edits/cut_safety.py). skip_counts maps discourse:{token} to kept uses and backchannel:{phrase} to kept acknowledgments (uh huh). word_probe:unavailable is a missing Whisper model; word_probe:failed is a span whose decode raised. The summary names both. edit_mode is ripple (default, from tighten.edit_mode) or mute. Mute proposes EditDecisionType.MUTE filler hits and skips pause candidates (muting a pause is a no-op). A pause: trim is shrunk to the air inside the pause, labelled :air_edges when it differs from the span pacing proposed, and proposed only when it removes at least a tenth of its pause (imperceptible skips the rest). It is reviewed or applied by the checks a filler gets. intensity is light / medium / aggressive (default from tighten.intensity, else medium): a deterministic preset over existing tighten keys (light = clustered um/uh only and >=0.5 s pause air; medium also proposes a lone um/uh; aggressive = isolated and borderline discourse markers, 0.3 s solo pauses). Unknown values raise. Suggest a tier from the episode (interview -> light, solo monologue -> aggressive); the pipeline itself never chooses. Pipeline auto-tighten stays off; listen-first review before apply_edits / approve_edits. Not NL cut-by-text (cut_* tools) or narrative focus (focus tools).

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

Input Schema

Name	Required	Description	Default
`edit_mode`	No
`intensity`	No
`project_path`	No

Output Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed5 schema fields changedv0.1.1Oct 19, 2026

addedInput schema / properties / intensity

Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Intensity"
+}

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 / required
```
Removed value: -[
-  "project_path"
-]
```

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 richly: it states this is a proposal-only, non-applying operation, that unknown intensity values raise, that mute mode skips pause candidates (a no-op), that pause trims are shrunk to air and labelled ':air_edges', and that proposals are gated by an imperceptibility threshold. This is well beyond what any annotation or schema conveys.

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?

The core purpose is front-loaded in the first sentence and most sentences carry real operational detail. It is long and dense, and some of the output-shape and skip_counts enumeration overlaps with the declared output schema, but the density is largely earned for a tool with this many internal modes.

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?

For a complex, multi-mode tool this is nearly complete: mode semantics, intensity presets, skip-token meanings, and the review-before-apply workflow are all covered. Its gaps are the unexplained project_path parameter and some redundancy with the existing output schema rather than missing essentials.

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 description coverage is 0% and none of the three params carry enums, so the description must compensate — and it does for two: edit_mode ('ripple' default from tighten.edit_mode, or 'mute') and intensity (light/medium/aggressive with config fallbacks and 'unknown values raise'). project_path receives no explanation, leaving one of three parameters 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?

Opens with a specific verb+resource and scope: 'Propose filler/pause tighten edits for review (does not apply them)'. It explicitly differentiates itself from apply_edits/approve_edits (the apply path) and from 'NL cut-by-text (cut_* tools)' and 'narrative focus (focus tools)', so an agent can route correctly among a very crowded sibling set.

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 guidance: 'listen-first review before apply_edits / approve_edits', 'Pipeline auto-tighten stays off', and a tier-selection heuristic ('interview -> light, solo monologue -> aggressive') while noting the pipeline never chooses on its own. It also names the exclusion alternatives (cut_* and focus tools), satisfying the when/when-not/alternatives bar.

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

Deploy Server