Skip to main content
Glama
calebn

Podcast MCP

by calebn
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

set_word_suppressed_tool

Toggle whether a specific transcript word in a podcast track is suppressed. Specify track, word index, and boolean state; use expected text to prevent edits if the word changed.

Instructions

Toggle suppressed on one per-track word (TOOL_TIMEBASE: source).

Pass expected_text (the word text you read) to refuse the toggle if the word at word_index changed meanwhile; omit to skip. source_id names the recording whose words word_index counts; it is required on a track recorded as several takes, and the refusal is word_source_required.

Input Schema

NameRequiredDescriptionDefault
track_idYes
source_idNo
suppressedYes
word_indexYes
project_pathNo
expected_textNo

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed6 schema fields changedv0.1.1
    • addedInput schema / properties / expected_text
      Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Expected Text"
+}
    • 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 / source_id
      Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Source Id"
+}
    • changedInput schema / required
      Previous value: -[
-  "project_path",
-  "track_id",
-  "word_index",
-  "suppressed"
-]New value: +[
+  "track_id",
+  "word_index",
+  "suppressed"
+]
  2. First observedv0.1.0

TDQS

B3.4/5.0
Behavior3/5

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

No annotations exist, so the description carries the full burden. It does disclose genuinely useful behavior: optimistic-concurrency refusal via expected_text and a named failure mode (word_source_required). It does not say whether suppression is reversible/undoable, what suppression does to downstream audio or export, or what permissions are needed.

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 and follows with parameter-specific notes; no filler. The parenthetical 'TOOL_TIMEBASE: source' is jargon that costs a reader more than it returns.

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 no explanation, and the concurrency/failure story is covered. What's missing for a mutation tool with zero annotations is the semantics of 'suppressed' itself and the role of project_path — an agent can call it correctly but cannot predict consequences.

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 coverage is 0%, so the description must compensate across 6 parameters. It explains expected_text (safety check), source_id (required on multi-take tracks, names the recording that word_index counts within), and implicitly word_index. It leaves track_id, suppressed (what the flag actually means downstream), and project_path completely undefined.

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: toggling 'suppressed' on exactly one per-track word, scoped to a source timebase. That distinguishes it implicitly from the bulk suppression siblings (apply_low_audibility_suppression_tool, apply_bleed_suppression_tool) and from per-word cousins like set_word_timing_tool, though no sibling is named explicitly.

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?

Gives real conditional guidance for how to call it — pass expected_text to refuse the toggle if the word changed, omit to skip — and when source_id is mandatory (multi-take tracks). It never says when to prefer this tool over the bulk suppression or apply_transcript_gate_tool alternatives, so tool selection guidance is only implied.

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