Skip to main content
Glama
nmbrthirteen

podcli

by nmbrthirteen
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

transcribe_start

Start transcription as a background job for long audio files. Returns a job ID to track progress and retrieve the transcript when done.

Instructions

Start transcription as a background job and return a job_id immediately. Use this instead of transcribe_podcast for long files so you can narrate progress to the user while it runs (a 60-min episode takes 15–25 min).

Flow: call transcribe_start(file_path) → emit status text to user → call job_status(job_id, wait_seconds: 30) in a loop until done → then read the packed transcript via get_ui_state(include_transcript: true).

Requires the Web UI to be running (npm run ui). Returns { job_id, cached, status, estimate_minutes }.

Input Schema

NameRequiredDescriptionDefault
engineNo
languageNo
file_pathYes
model_sizeNobase
num_speakersNo
enable_diarizationNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv2.8.0
    • changedInput schema / properties / engine / enum
      Previous value: -[
-  "whisper-py",
-  "whispercpp",
-  "assemblyai"
-]New value: +[
+  "whisper-py",
+  "whispercpp",
+  "assemblyai",
+  "omnilingual"
+]
  2. Changed1 schema field changedv2.7.3
    • changedInput schema / properties / enable_diarization / default
      Previous value: -falseNew value: +true
  3. Changed1 schema field changedv2.7.2
    • removedInput schema / additionalProperties
      Removed value: -false
  4. Changed1 schema field changedv2.5.0
    • changedInput schema / properties / enable_diarization / default
      Previous value: -trueNew value: +false
  5. Changed1 schema field changedv2.3.0
    • addedInput schema / properties / engine
      Added value: +{
+  "enum": [
+    "whisper-py",
+    "whispercpp",
+    "assemblyai"
+  ],
+  "type": "string"
+}
  6. First observedv2.0.0

TDQS

A4.4/5.0
Behavior5/5

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

No annotations are provided, so the description carries the full burden and it does: it discloses the async/background nature, the required runtime dependency ('Requires the Web UI to be running (npm run ui)'), long-running timing, and even the return shape { job_id, cached, status, estimate_minutes }. That is unusually complete behavioral disclosure.

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, then a clearly labeled 'Flow:' sequence and a prerequisites/returns trailer. It is longer than most descriptions but nearly every sentence carries actionable information; only mild density could be trimmed.

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 an async orchestration tool with no output schema and no annotations, the description supplies the missing pieces: return fields, runtime prerequisite, timing expectation, and the follow-up loop. Only the non-file_path parameters are uncovered, which is scored separately.

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% across 6 parameters, and the description only demonstrates file_path usage. Engine, language, model_size, num_speakers, and enable_diarization (two with enums, one with a default) are left with no semantic guidance anywhere, so the description fails to compensate for the schema gap.

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?

States a specific verb and resource ('Start transcription as a background job') and immediately distinguishes itself from the sibling transcribe_podcast. An agent can tell apart the async variant from the sync one without opening either schema.

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?

Explicitly names the alternative and the condition that selects it ('use this instead of transcribe_podcast for long files'), plus a concrete duration heuristic (60-min episode = 15-25 min). It goes further and gives an end-to-end call flow naming job_status and get_ui_state.

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