Crawl-MCP

Overview Schema Source Related Servers Discussions Admin

get_youtube_video_info

Read-only

Extract YouTube video metadata and transcript availability; set output_path to save the full transcript as markdown and get a slim response.

Instructions

Get YouTube video metadata and transcript availability. Use output_path to persist the full transcript to disk as markdown and receive a slim response.

Input Schema

Name	Required	Description	Default
`timezone`	No	IANA timezone name (e.g. 'Asia/Tokyo', 'America/New_York') used to convert the video's publish time, returned under 'published_at'. When unspecified, defaults to 'UTC' (the original YouTube offset is always kept in published_at.original).	UTC
`llm_model`	No	LLM model
`overwrite`	No	Overwrite an existing output file at output_path. Defaults to False.
`video_url`	Yes	YouTube video URL
`max_tokens`	No	Token limit for summarization
`output_path`	No	Absolute file path (auto .md extension) to persist the full video info + transcript as markdown. When set, the response is slimmed to metadata+file path.
`llm_provider`	No	LLM provider
`summary_length`	No	'short'\|'medium'\|'long'	medium
`include_timestamps`	No	Include timestamps
`summarize_transcript`	No	Summarize transcript
`include_content_in_response`	No	When True (with output_path set), also include the full transcript in the response. 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 'published_at'. When unspecified, defaults to 'UTC' (the original YouTube offset is always kept in 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?

The description usefully discloses the file-persistence side effect and the response-shape trade-off (slim response when output_path is set), which goes beyond the readOnlyHint annotation. It says nothing about the LLM-backed summarization path being invoked by summarize_transcript, which carries latency and cost implications for an agent, and it omits any noting of the tension between a filesystem write and readOnlyHint=true.

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?

Two tight sentences with the core capability front-loaded and the persistence behavior second. Nothing is padded and every clause carries information.

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?

With eleven parameters, an output schema, and only a readOnlyHint annotation, the description should convey the tool's full capability set. It never says the tool can summarize the transcript or return full content in the response, leaving two of the most consequential modes to be discovered only by reading the schema.

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 eleven parameters are already documented in the schema, including the slim-response behavior of output_path. The description restates that one behavior but adds no syntax or semantic detail for llm_model, max_tokens, summarize_transcript, summary_length, or include_timestamps, so the baseline of 3 applies.

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 gives a specific verb and resource ("Get YouTube video metadata and transcript availability") that an agent can act on immediately. However, it never distinguishes this tool from close siblings like extract_youtube_transcript or batch_extract_youtube_transcripts, and it understates its own scope by framing the output as mere "transcript availability" when the schema shows summarization and full-transcript retrieval options.

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 second sentence gives one concrete usage rule — set output_path to get a persisted markdown transcript plus a slim response — which is implied guidance on when the parameter matters. But there is no statement of when to prefer this tool over extract_youtube_transcript, no exclusion of cases where it is a poor fit, and no mention of when to enable summarize_transcript.

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