Crawl-MCP

Overview Schema Source Related Servers Discussions Admin

extract_youtube_transcript

Read-only

Extract transcripts with timestamps from public captioned YouTube videos and save full markdown copies to disk for later analysis.

Instructions

Extract YouTube transcripts with timestamps. Works with public captioned videos. Supports fallback to page crawl. Use output_path to persist the full unsliced transcript to disk as markdown.

Input Schema

Name	Required	Description	Default
`url`	Yes	YouTube video URL
`timezone`	No	IANA timezone name (e.g. 'Asia/Tokyo', 'America/New_York') used to convert the video's publish time, returned under metadata.published_at (requires enrich_metadata=True). When unspecified, defaults to 'UTC' (the original YouTube offset is always kept in metadata.published_at.original).	UTC
`languages`	No	Language codes in preference order
`llm_model`	No	LLM model
`overwrite`	No	Overwrite an existing output file at output_path. Defaults to False.
`output_path`	No	Absolute file path (auto .md extension) to persist the full unsliced transcript. When set, the response is slimmed to metadata+file path. content_limit/content_offset still affect the response copy but not the on-disk file.
`llm_provider`	No	LLM provider
`translate_to`	No	Target language for translation
`content_limit`	No	Max characters to return (0=unlimited)
`auto_summarize`	No	Auto-summarize large content
`content_offset`	No	Start position for content (0-indexed)
`summary_length`	No	'short'\|'medium'\|'long'	medium
`enrich_metadata`	No	Enrich metadata (upload_date, view_count) via page crawl
`fallback_timeout`	No	Fallback crawl timeout in seconds
`include_metadata`	No	Include video metadata
`include_timestamps`	No	Include timestamps
`max_content_tokens`	No	Max tokens before summarization
`preserve_formatting`	No	Preserve formatting
`enable_crawl_fallback`	No	Enable page crawl fallback when API fails
`include_content_in_response`	No	When True (with output_path set), keep the transcript in the response too. Note: the response copy is still subject to content_limit/content_offset slicing; only the on-disk file holds the full transcript. Defaults to False.

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedv0.4.2Oct 31, 2026

addedInput schema / properties / timezone

Added value: +{
+  "default": "UTC",
+  "description": "IANA timezone name (e.g. 'Asia/Tokyo', 'America/New_York') used to convert the video's publish time, returned under metadata.published_at (requires enrich_metadata=True). When unspecified, defaults to 'UTC' (the original YouTube offset is always kept in metadata.published_at.original).",
+  "type": "string"
+}

Addedv0.3.2May 20, 2026
Removedv0.1.6May 1, 2026
First observedv0.1.7Feb 7, 2026

TDQS

A3.5/5.0

Behavior3/5

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

readOnlyHint=true already tells the agent this is a safe network read. The description adds useful context – crawl fallback and that output_path writes the full unsliced transcript to disk, plus that the response copy is slimmed. However, it doesn't surface the heavier behaviors (auto_summarize, llm translate) that the tool also exposes, leaving a gap relative to what the tool can do.

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 short sentences, front-loaded with the core action, no filler. Every sentence earns its place; each covers a distinct concern (what, constraint, fallback, persistence).

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, so return-value explanation isn't required, freeing the description to focus on behavior. For a 20-param tool it's reasonably complete, though it never acknowledges the translation/summarization features, so an agent must read the schema to discover them.

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 the input schema fully documents all 20 params; baseline is 3. The description does add real meaning for output_path (persists unsliced transcript, response slimmed) and timestamps, but says nothing about translation, summarization, or language ordering beyond what the schema states.

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+resource: 'Extract YouTube transcripts'. Adds scope details (with timestamps, public captioned videos, fallback to page crawl). It does not explicitly distinguish itself from batch_extract_youtube_transcripts or extract_youtube_comments, so sibling differentiation is left implicit.

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?

'Works with public captioned videos' gives a constraint, and the output_path sentence implies a persistence workflow. But there is no explicit when-to-use versus the batch or comments variants, and no mention of prerequisites beyond the public-captioned hint.

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