Skip to main content
Glama

tidewell/media-transcriber

tidewell--media-transcriber
Destructive

This tool calls the Actor "tidewell/media-transcriber" and retrieves its output results. Actor description: Returns a transcript per audio or video file: text, timestamped segments, detected language, SRT and VTT subtitles and optional word timestamps, with Whisper in 99 languages. Input: MP3, MP4, WAV and other media links, podcast RSS feeds or Apple Podcasts links. From $0.004 per audio minute.

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": "tidewell--media-transcriber"
  }
}

Input Schema

NameRequiredDescriptionDefault
taskNotranscribe: text in the spoken language. translate: English translation of any language (Whisper's built-in speech translation). Example values: "transcribe"transcribe
modelNoBigger models are more accurate (names, accents, noisy audio, non-English) but slower and priced higher per minute. base is a good default for clear speech; small is noticeably better for most languages. Example values: "base"base
languageNoSpoken language. Auto-detect works well; set it when you know it, which avoids rare detection mistakes on short or noisy clips. Codes such as en, es, de, fr, ja; the most-used languages are listed first. Example values: "auto"auto
waitSecsNoMax seconds (0–45, default 30) to cap the wait for the Actor run to reach terminal state. For long-running Actors the response returns at the cap with the current run status; follow `nextStep` to poll via get-actor-run. Set to 0 to fire-and-forget.
mediaUrlsNoDirect links to audio or video files (MP3, M4A, WAV, FLAC, OGG, OPUS, AAC, MP4, MOV, WEBM, MKV and more), podcast RSS feeds, Apple Podcasts show or episode links, or web pages that embed an audio/video file. Google Drive and Dropbox share links work. YouTube, TikTok, Instagram, Spotify and similar platform pages are not supported. Example values: ["https://archive.org/download/life_poem_21_dickinson/life_21_dickinson_ad_64kb.mp3"]
vadFilterNoSilero voice activity detection skips silence and non-speech, which is faster and avoids made-up text in silent parts. Turn off only if quiet speech is being skipped. Example values: true
httpHeadersNoHeaders sent with every download, e.g. {"Authorization": "Bearer ..."} for private file servers or private podcast feeds.
initialPromptNoNames, jargon or spelling to steer the transcript, e.g. "Kubernetes, Grafana, Dr. Nkemelu". Keep it short.
maxFileSizeMbNoFiles larger than this are skipped (not charged). Video files are large: about 1 GB per hour of HD video is common. Example values: 2000
uploadedFilesNoUpload files from your computer. They are stored in a key-value store and transcribed like media URLs.
wordTimestampsNoAdd every word with its start, end and confidence to the dataset row and the JSON file. Free (subtitles always use word timing internally).
subtitleMaxLinesNoMaximum lines per subtitle cue. Example values: 2
episodeTitleFilterNoOnly episodes whose title contains this text (case-insensitive). Separate alternatives with |, e.g. "interview|Q&A".
maxDurationMinutesNoTranscribe at most the first N minutes of each file (you pay only for what is transcribed). Empty = whole file.
maxEpisodesPerFeedNoHow many episodes to transcribe from each podcast feed, newest first, after the filters below. 0 = all matching episodes. Example values: 1
downloadTimeoutSecsNoMaximum time to download one file. Example values: 900
subtitleMaxLineLengthNoMaximum characters per subtitle line in the SRT/VTT files. 42 is the broadcast standard. Example values: 42
episodesPublishedAfterNoOnly episodes published on or after this date: YYYY-MM-DD, or relative like "30 days" or "2 weeks".
episodesPublishedBeforeNoOnly episodes published before this date (YYYY-MM-DD).

Output Schema

NameRequiredDescriptionDefault
tipNoAdvisory guidance RAG Web Browser wrote to its key-value store under the reserved "TIP" key
runIdYesActor run ID
statsNoRun statistics
statusYesRun status: READY | RUNNING | TIMING-OUT | TIMED-OUT | ABORTING | ABORTED | SUCCEEDED | FAILED
actorIdYesStable Apify Actor ID from the run record
summaryYesPast-tense summary of the run state
exitCodeNoActor process exit code; populated for terminal states (especially FAILED)
nextStepYesOne primary follow-up action with identifiers interpolated
storagesYesDataset and key-value store metadata, keyed by alias. "default" is always the primary entry.
actorNameNo"username/actor-name"
startedAtNoISO timestamp when the run started
finishedAtNoISO timestamp when the run finished (terminal states only)
statusMessageNoPass-through from Apify run.statusMessage
apifyConsoleUrlNoPersonalized Apify Console link to the run; present only for Console sessions

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • changedOutput schema / properties / storages / properties / datasets / additionalProperties / properties / fields / description
      Previous value: -"Dataset field paths in dot notation (e.g. [\"metadata.url\"])"New value: +"Paths that work as a fields selection (e.g. [\"results\", \"metadata.url\"]); an array field appears by its top-level name."
    • changedOutput schema / properties / storages / properties / datasets / properties / default / properties / fields / description
      Previous value: -"Dataset field paths in dot notation (e.g. [\"metadata.url\"])"New value: +"Paths that work as a fields selection (e.g. [\"results\", \"metadata.url\"]); an array field appears by its top-level name."
  2. First observed

TDQS

A3.5/5.0
Behavior3/5

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

Annotations already declare readOnlyHint=false, destructiveHint=true and openWorldHint=true, and the description complements them with cost disclosure ('From $0.004 per audio minute') plus the output shape. It does not disclose the run lifecycle behavior that materially affects invocation — that this starts an asynchronous Actor run, that the call may return before completion with a run status and a nextStep to poll, or that per-file failures are not charged (that detail lives only in the schema). Nothing here contradicts the annotations.

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 sentences, front-loaded with what the tool does, then outputs, inputs and price. Prose is tight and free of filler. The only soft spot is the boilerplate 'calls the Actor ... and retrieves its output results' framing, which is a wrapper artifact rather than task-relevant information.

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?

An output schema exists and the 19 parameters are fully documented, so the description does not need to explain return values and mostly doesn't. It covers the essentials an agent needs to call it: supported inputs, what comes back, and cost. The missing piece is the asynchronous run/poll contract, which matters given the waitSecs parameter and the presence of get-actor-run as a sibling.

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 100% across all 19 parameters, including enums, defaults and format notes for media URLs, VAD, word timestamps and podcast filters, so the schema already carries the semantics. The description restates input formats and output artifacts but adds no parameter-level meaning beyond what the schema provides. Baseline 3 applies where structured fields do the heavy lifting.

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?

The description states a specific verb and resource: it runs the 'tidewell/media-transcriber' Actor and returns a transcript per audio/video file with text, timestamped segments, detected language, SRT/VTT subtitles and optional word timestamps. That is concrete and unambiguous. It does not, however, distinguish itself from siblings such as get-actor-run or get-dataset-items, which are the natural follow-on tools in this Actor-run workflow.

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?

Usage scope is implied through the accepted inputs ('MP3, MP4, WAV and other media links, podcast RSS feeds or Apple Podcasts links'), which lets an agent judge fit. But there is no explicit when-to-use/when-not statement and no named alternative for related tasks (e.g. polling a run, fetching already-produced dataset items), so the agent must infer routing from sibling names alone.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources