Skip to main content
Glama

Transcribe media file URLs on your own key

transcribe_media_urls
Read-only

Transcribe direct audio or video file URLs with your own Deepgram, AssemblyAI, Groq, or OpenAI key and return transcripts with timestamped segments, language, and duration.

Instructions

Give direct audio or video file links and your own Deepgram, AssemblyAI, Groq, or OpenAI key. Returns one row per file with the transcript, timestamped segments, language, and duration. Platform pages such as YouTube are refused. With no key it checks up to 3 files for free. Pay per event on Apify: 0.005 USD per media minute, plus your provider's bill.

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

Input Schema

NameRequiredDescriptionDefault
modelNoOptional. The provider's model name. Defaults: deepgram nova-3, assemblyai its own default, groq whisper-large-v3-turbo, openai whisper-1 (the only one accepted there).
api_keyNoYour own key for the provider above. It is stored encrypted by Apify, sent only to that provider, and never written to a row or a log. With no key the run checks up to 3 files and transcribes nothing, for free.
diarizeNoyes or no (default no). Labels who spoke each segment. deepgram and assemblyai only; your provider may bill it as an add on.
languageNoOptional. A language code such as en or de. Empty lets deepgram and assemblyai detect it; whisper models detect it on their own.
providerNoWhose API transcribes the file, on your key: deepgram (default), assemblyai, groq, or openai. openai takes files up to 25 MB; the others read the URL.
media_urlsNoDirect links to audio or video files (mp3, wav, m4a, mp4, and others) that answer without a login. Platform pages such as YouTube, TikTok, Instagram, Vimeo, or Spotify are refused with a free row. In Clay, put the column inside a one item list.
max_charge_usdNoOptional. No new file starts once this is used up. A transcript your provider already billed is still delivered, charged up to this amount, and the run then stops. It limits this actor's charge, not your provider's bill.
include_segmentsNoyes (default) or no. Adds a list of segments with start and end seconds to each row.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.3/5.0
Behavior4/5

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

Beyond the annotations, the description discloses the per-file row output, included transcript fields, platform-page refusal behavior, free no-key checks, and pricing including the provider's separate bill. This adds meaningful operational and cost context that annotations do not cover. It stops short of describing runtime or asynchronous behavior.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is four sentences, front-loads the input requirement, and each sentence carries useful information: output shape, refused inputs, free tier, and pricing. There is no redundant or filler wording.

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 eight-parameter tool with no output schema, the description covers purpose, expected output, input restrictions, cost, and free-tier behavior. The annotations already cover safety traits, and the schema fully covers parameters, so nothing essential is missing.

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%, so all eight parameters are already well documented in the input schema. The description mentions provider choice and the no-key behavior, but adds no parameter syntax or constraints beyond what the schema already provides. The baseline of 3 is appropriate.

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?

The description states a specific verb and resource: transcribe direct audio or video file URLs using the caller's own provider key. It immediately distinguishes acceptable inputs from refused ones such as YouTube, and it names the returned fields, so an agent can identify the tool without opening the schema.

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

Usage Guidelines4/5

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

It clearly says to supply direct file links and states that platform pages such as YouTube are refused, which is a useful when-not condition. It also explains the no-key free check. It does not name alternative tools, but no siblings exist, so the guidance is effectively complete.

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