Skip to main content
Glama

fetch_transcript

Fetch captions from any video URL and return a cleaned text transcript, saving a .txt file to output. Uses YouTube's transcript API and yt-dlp fallback for other platforms.

Instructions

Grab an agent-friendly transcript for a video URL without downloading the media. YouTube uses youtube-transcript-api (fast); every other platform falls back to the yt-dlp caption pass. Writes a .txt (plus .vtt on request) into the output dir and returns the cleaned text.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
urlYes
languageNo
want_vttNo
prefer_autoNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A3.8/5.0
Behavior4/5

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

With no annotations, the description carries full responsibility for disclosing behavior. It clearly states side effects (writes .txt/.vtt files), return value (cleaned text), and platform-specific implementation (YouTube vs others). It lacks failure-mode details (e.g., missing captions) but covers the core behavioral contract.

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 three sentences with zero filler. It front-loads the primary purpose and constraint, then adds platform behavior and output format. Every sentence provides essential information, making it highly efficient.

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?

The description covers the main flow (fetch, write, return) and platform differences, but omits critical parameter semantics (language, prefer_auto) and failure scenarios. Given the tool has 4 parameters and no annotations, it falls short of being fully complete, though it does address the most salient aspects.

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%, so the description must compensate for parameter meaning. It indirectly explains 'url' (video URL) and 'want_vtt' ('.vtt on request'), but does not explain 'language' or 'prefer_auto' at all. This is insufficient for a tool with four parameters.

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 clearly states a specific verb ('Grab') and resource ('transcript for a video URL'), and explicitly distinguishes itself from downloading media, which separates it from sibling tools like download_audio. It also notes platform-specific behavior, making its purpose unambiguous.

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?

The description implies when to use this tool (when you need a transcript without downloading media) but does not explicitly mention alternatives like transcribe_video or list_available_transcripts, nor does it state when not to use it. The platform-specific note is more behavioral than usage guidance, so it's adequate but not explicit.

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