This server provides AI-powered, local multi-modal analysis of YouTube videos — no API keys required. It supports standard YouTube URL formats (youtube.com/watch?v=ID, youtu.be/ID, youtube.com/shorts/ID).
Summarize videos (summarize_video): Generate text summaries at three detail levels — brief (2-3 sentences), medium (key points with timestamps), or detailed (comprehensive breakdown).
Ask questions about videos (ask_about_video): Pose specific questions and get AI-generated answers based on the video's content.
Extract screenshots automatically (extract_screenshots): AI identifies visually significant moments and extracts frames as base64 images, with configurable count (1-20), focus area, resolution (thumbnail to full), and optional disk saving.
Preview important timestamps (get_video_timestamps): Identify key moments and retrieve their timestamps without extracting frames — useful for planning before committing to extraction.
Extract frames at specific timestamps (extract_frames): Supply exact timestamps to retrieve corresponding frames, with configurable resolution and optional disk saving.
Underlying capabilities include local Whisper-based transcription, scene-change/interval keyframe extraction, and audio analysis (energy, tempo, RMS, music vs. speech detection via librosa).
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@yt-mcp summarize https://www.youtube.com/watch?v=dQw4w9WgXcQ"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
A fully local MCP (Model Context Protocol) server that gives AI assistants deep, multi-modal awareness of YouTube videos. No API keys required. All processing runs on-device via yt-dlp, OpenAI Whisper, FFmpeg, PySceneDetect, and librosa.
Note: This repository also contains an experimental TypeScript server (
src/) that uses the Gemini API. That server is not under active development — the Python local server (server/) is the primary implementation.
Related MCP server: yt-analysis-mcp
yt-mcp runs as a local subprocess that an AI assistant spawns and talks to over stdio using JSON-RPC 2.0. The assistant calls tools; the server downloads the video once, extracts multi-modal signals on-device, caches everything to disk, and returns structured JSON. No data leaves the machine except the one-time download from YouTube.
flowchart LR
subgraph client["AI Assistant"]
A["Claude Code / Desktop"]
end
subgraph server["yt-mcp · local subprocess"]
M["FastMCP server<br/>get_video_transcript · get_video_frames<br/>get_audio_features · get_full_context"]
P["Local pipeline<br/>yt-dlp · Whisper · FFmpeg<br/>PySceneDetect · OpenCV · librosa"]
C[("Disk cache<br/>/tmp/yt-analysis-cache/<video_id>")]
M --> P
P <--> C
end
YT[("YouTube")]
A -- "JSON-RPC 2.0 (stdio)" --> M
M -- "JSON result" --> A
P -- "download once" --> YT
classDef store fill:#fff3cd,stroke:#d39e00,color:#332701;
class C,YT store;A single download feeds three parallel analysis tracks, which timeline.py then re-aligns into one time-indexed JSON document.
flowchart TD
URL([YouTube URL]) --> DL["<b>yt-dlp</b><br/>download video.mp4<br/>extract audio.wav · 16 kHz mono"]
DL -->|audio.wav| W["<b>Whisper</b><br/>word-level transcript"]
DL -->|video.mp4| SD["<b>PySceneDetect</b><br/>scene-cut timestamps"]
DL -->|audio.wav| LR["<b>librosa</b><br/>energy · tempo · music vs speech"]
SD --> FF["<b>FFmpeg</b><br/>keyframe JPEG at each cut"]
SD --> CV["<b>OpenCV</b><br/>pixel-diff animation detection"]
W --> TL["<b>timeline.py</b><br/>unified, time-aligned segments"]
FF --> TL
CV --> TL
LR --> TL
TL --> OUT([Structured JSON → MCP client])
classDef io fill:#d1e7dd,stroke:#0f5132,color:#03190f;
class URL,OUT io;All results are cached in /tmp/yt-analysis-cache/<video_id>/. Re-calling the same URL is instant — only the first call pays the download + transcription cost.
# macOS
brew install ffmpeg
# Ubuntu / Debian
sudo apt install ffmpeg
# Verify
ffmpeg -version
python3 --version # must be 3.10+Dependencies are managed with uv. Install it first if you
don't have it (brew install uv, or see the install guide).
git clone https://github.com/yourusername/yt-mcp.git
cd yt-mcp
# Create the virtual environment (.venv) and install all dependencies from uv.lock
uv syncuv sync creates a .venv/ in the project directory and installs the exact, locked
versions of every dependency — including the dev tools (pytest). Add --no-dev to
install runtime dependencies only.
Whisper model weights download automatically on the first transcription call (~142 MB for base, ~2.9 GB for large).
MCP clients spawn the server as a subprocess — they do not activate your shell or venv automatically. You must point them at the venv's Python interpreter directly using its absolute path.
uv sync puts the interpreter at .venv/bin/python. Get its absolute path:
realpath .venv/bin/python # e.g. /Users/you/repos/yt-mcp/.venv/bin/pythonClaude Code:
claude mcp add -s user yt-mcp -- /path/to/yt-mcp/.venv/bin/python /path/to/yt-mcp/server/main.pyClaude Desktop — add to ~/Library/Application Support/Claude/claude_desktop_config.json:
{
"mcpServers": {
"yt-mcp": {
"command": "/path/to/yt-mcp/.venv/bin/python",
"args": ["/path/to/yt-mcp/server/main.py"]
}
}
}Replace
/path/to/yt-mcpwith the absolute path to wherever you cloned the repo. On Windows the interpreter is at.venv\Scripts\python.exe.
Prefer not to install FFmpeg, Python, and the ML stack on the host? Build the
image and let the MCP client spawn it. The server speaks MCP over stdio, so
the container must be run with -i (interactive stdin):
docker build -t yt-mcp .
docker run -i --rm -v yt-mcp-cache:/data/cache yt-mcpWire it into a client the same way as the local install, but with docker as the
command:
claude mcp add -s user yt-mcp -- docker run -i --rm -v yt-mcp-cache:/data/cache yt-mcpThe -v yt-mcp-cache:/data/cache volume persists downloaded videos and Whisper
model weights across runs. The image installs the CPU-only build of PyTorch
on purpose — see docs/deployment.md for the build details,
the cache layout, and the rationale (plus how to build a GPU variant).
The server exposes four tools. get_full_context is the primary one — it combines every signal into a single timeline. Reach for the others when you need just one modality or want to control token usage.
flowchart TD
Q{"What do you need?"}
Q -->|"Complete situational awareness"| FC["<b>get_full_context</b><br/>transcript + scenes + audio,<br/>time-aligned · start here"]
Q -->|"Exact words + timestamps"| TR["<b>get_video_transcript</b><br/>Whisper, word-level"]
Q -->|"Visual keyframes"| FR["<b>get_video_frames</b><br/>JPEGs at scene cuts / intervals"]
Q -->|"Energy · tempo · music"| AU["<b>get_audio_features</b><br/>librosa, per window"]
classDef primary fill:#cfe2ff,stroke:#084298,color:#031633;
class FC primary;Tool | Modality | Returns base64 images? | Safe for long videos? |
| All (transcript + scene + audio) | Only if | Yes (default |
| Speech → text | No | Yes |
| Visual | Yes (always) | Use on short clips / specific ranges |
| Audio | No | Yes |
get_video_transcriptTranscribe a YouTube video using OpenAI Whisper (runs entirely locally).
Parameter | Type | Default | Description |
| string | — | Full YouTube URL |
| string |
|
|
Response:
{
"title": "Video Title",
"duration": 847,
"language": "en",
"full_text": "Welcome to this video...",
"segments": [
{
"t_start": 0.0,
"t_end": 4.5,
"text": "Welcome to this video.",
"words": [{ "word": "Welcome", "start": 0.0, "end": 0.6 }]
}
]
}get_video_framesExtract keyframes as base64-encoded JPEGs. Uses PySceneDetect for scene detection and FFmpeg for extraction.
Parameter | Type | Default | Description |
| string | — | Full YouTube URL |
| string |
|
|
| integer |
| Seconds between frames (for |
Response:
{
"title": "Video Title",
"duration": 847,
"duration_formatted": "14:07",
"frame_count": 12,
"strategy": "scene",
"frames": [
{
"t": 0.0,
"t_formatted": "0:00",
"keyframe": "<base64 JPEG>",
"scene_change": false,
"animation_detected": false
}
],
"summary": [ /* same list without keyframe bytes — for quick review */ ]
}get_audio_featuresAnalyze audio characteristics using librosa (runs locally).
Parameter | Type | Default | Description |
| string | — | Full YouTube URL |
| integer |
| Analysis window size in seconds |
Response:
{
"title": "Video Title",
"duration": 847,
"segment_duration": 30,
"segments": [
{
"t_start": 0.0,
"t_end": 30.0,
"energy": "medium",
"music": false,
"tempo_bpm": 95.0,
"rms_db": -22.1
}
]
}get_full_contextPrimary tool. Returns a complete, synchronized multi-modal timeline — transcript + scene boundaries + animation detection + audio features, all time-aligned.
Parameter | Type | Default | Description |
| string | — | Full YouTube URL |
| boolean |
| Embed base64 keyframes per segment |
| string |
| Whisper model size |
Response:
{
"title": "How Transformers Work",
"channel": "AI Explained",
"duration": 847,
"duration_formatted": "14:07",
"language": "en",
"description": "In this video...",
"segments": [
{
"t_start": 0.0,
"t_end": 12.0,
"transcript": "Welcome to this video on transformers...",
"keyframe": null,
"scene_change": false,
"animation_detected": false,
"audio": {
"energy": "low",
"speech_rate": "normal",
"music": true,
"tempo_bpm": 0.0,
"rms_db": -28.4
}
}
]
}Context window tip: Call
get_full_contextwithinclude_frames=falsefirst to understand the video structure, then callget_video_framesfor specific timestamps of interest.
https://www.youtube.com/watch?v=VIDEO_ID
https://youtu.be/VIDEO_ID
https://youtube.com/shorts/VIDEO_IDVariable | Default | Description |
|
| Cache directory for downloaded videos and audio |
# Run the server directly (stdio mode — same as MCP clients use)
# `uv run` executes inside the project venv without needing to activate it
uv run python server/main.py
# Quick smoke test
uv run python -c "
from server.utils.downloader import VideoDownloader
from server.tools.transcript import get_transcript
d = VideoDownloader()
vp, ap, info = d.download('https://www.youtube.com/watch?v=jNQXAC9IVRw')
print(get_transcript(ap)['language'])
"The Python server has a full unit test suite — 164 tests across 6 modules. All tests run without any network access or model downloads; every external dependency (Whisper, librosa, FFmpeg, PySceneDetect, OpenCV, yt-dlp) is mocked.
The dev dependencies (pytest, pytest-mock) are installed by uv sync — no separate step needed.
uv run pytestExpected output: 164 passed in ~4s
uv run pytest tests/test_downloader.py # VideoDownloader + VideoInfo
uv run pytest tests/test_transcript.py # Whisper wrapper + range helpers
uv run pytest tests/test_frames.py # FFmpeg, PySceneDetect, OpenCV
uv run pytest tests/test_audio.py # librosa AudioAnalyzer
uv run pytest tests/test_timeline.py # build_timeline + speech rate
uv run pytest tests/test_main.py # all 4 MCP tool handlersuv run pytest tests/test_timeline.py::TestBuildTimeline::test_rapid_cuts_below_min_merged -vThe example below uses プリマドンナ / 星街すいせい (Hoshimachi Suisei · Suisei Channel, 2:52) — a Japanese music video that exercises every layer of the pipeline: multilingual Whisper transcription, music detection via librosa HPSS, rapid scene cuts via PySceneDetect, and animation detection via OpenCV pixel-diff.
from server.utils.downloader import VideoDownloader
from server.tools.transcript import get_transcript
from server.tools.audio import AudioAnalyzer
from server.tools.frames import detect_scene_timestamps
URL = "https://www.youtube.com/watch?v=M1GYqy0tHV0"
d = VideoDownloader()
video_path, audio_path, info = d.download(URL)
print(f"Title: {info.title}") # プリマドンナ / 星街すいせい(official)
print(f"Duration: {info.duration:.0f}s") # 172
transcript = get_transcript(audio_path, model_size="base")
print(f"Language: {transcript['language']}") # ja
cuts = detect_scene_timestamps(video_path)
print(f"Scene cuts detected: {len(cuts)}") # typically 30–60 for a music video
analyzer = AudioAnalyzer(audio_path)
seg = analyzer.analyze_segment(0, 30)
print(f"First 30s — energy: {seg['energy']}, music: {seg['music']}")
# energy: 'medium' or 'high', music: TrueFor the full test guide — fixtures, mock patterns, writing tests for new tools — see docs/testing.md.
Document | What it covers |
Formal specification — tool contracts, data schemas, algorithms, thresholds, and the error model. The authoritative reference. | |
System design, data-flow and UML diagrams, and key design decisions | |
Component reference for every module | |
How to add new tools | |
Test suite structure, fixtures, and writing new tests | |
Docker build & run, MCP client config, cache volume, and the CPU-torch design decision | |
Running roadmap of planned improvements and ideas |
The src/ directory contains an experimental TypeScript server that delegates video analysis to the Gemini API. It is not under active development and is kept only for reference.
If you're looking for fast cloud-based video Q&A, the TypeScript server's approach (passing the YouTube URL directly to Gemini) works well for a quick prototype — but the Python server is the only implementation that will receive ongoing maintenance.
See docs/typescript-server.md for its API reference.
Ask a specific question about a YouTube video's content. Returns an answer based on the video.
| Name | Required | Description | Default |
|---|---|---|---|
| youtube_url | Yes | Full YouTube URL (youtube.com/watch?v=ID, youtu.be/ID, or youtube.com/shorts/ID) | |
| question | Yes | Your question about the video content |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden but only states it 'Returns an answer based on the video'. It does not disclose any behavioral traits such as rate limits, authentication needs, or what type of questions are supported. The statement is minimal but not misleading.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that conveys the core purpose efficiently. No wasted words, though it could include more detail without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 2 parameters and no output schema, the description provides a minimal but functional explanation. It lacks details about the format of the answer or limitations, which might be needed for effective use. However, it is not incomplete to the point of being unusable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents both parameters adequately. The description adds no new meaning beyond the schema, so a baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Describes the tool as asking a specific question about a YouTube video and returning an answer. The verb 'ask' and resource 'video content' are clear. However, it does not explicitly differentiate from sibling tools like 'summarize_video', which also deals with video content, though the 'specific question' aspect provides some distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implies usage when needing to ask a question about video content, but does not provide explicit guidance on when to use this tool versus alternatives like 'summarize_video' or when not to use it. No exclusions or prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Extract frames from a YouTube video at specific timestamps you provide. Use this when you already know the exact timestamps you want (e.g., from get_video_timestamps or video summary).
| Name | Required | Description | Default |
|---|---|---|---|
| youtube_url | Yes | Full YouTube URL (youtube.com/watch?v=ID, youtu.be/ID, or youtube.com/shorts/ID) | |
| timestamps | Yes | Array of timestamps in seconds to extract frames from (e.g., [5, 30, 60, 120]) | |
| output_dir | No | Optional directory to save screenshots. If not provided, uses SCREENSHOT_OUTPUT_DIR env var or temp directory. | |
| resolution | No | Output resolution: thumbnail (160p), small (360p), medium (720p), large (1080p), full (original). Default: large | large |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of behavioral disclosure. It focuses on the extraction function but doesn't detail behavior like file output format, naming conventions, or error handling. The description adds some context beyond schema but is not comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, directly stating the purpose and usage context with no fluff. It is concise and front-loaded with the key action and resource.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (4 parameters with 2 required) and no output schema, the description is adequate but not exhaustive. It covers the primary use case but lacks details on output behavior, which is acceptable since there is no output schema to complement.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds value by clarifying the usage context (timestamps from other tools) but does not provide additional semantic meaning beyond what the schema already offers for each parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool extracts frames from a YouTube video at specific timestamps. It specifies the resource (YouTube video) and the action (extract frames at timestamps), and distinguishes it from siblings like extract_screenshots by focusing on user-provided timestamps.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says when to use this tool: when you already know exact timestamps. It suggests examples like using timestamps from get_video_timestamps or video summary, implying when not to use it (if you don't have timestamps) and providing context for alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Extract key screenshots from a YouTube video at important moments. Uses AI to identify visually significant timestamps, then extracts frames. Returns both base64 images and optionally saves to disk.
| Name | Required | Description | Default |
|---|---|---|---|
| youtube_url | Yes | Full YouTube URL (youtube.com/watch?v=ID, youtu.be/ID, or youtube.com/shorts/ID) | |
| count | No | Number of screenshots to extract (1-20, default: 5) | |
| output_dir | No | Optional directory to save screenshots. If not provided, uses SCREENSHOT_OUTPUT_DIR env var or temp directory. | |
| focus | No | Optional focus for timestamp selection (e.g., 'product demos', 'code examples', 'diagrams'). Default analyzes for general key moments. | |
| resolution | No | Output resolution: thumbnail (160p), small (360p), medium (720p), large (1080p), full (original). Default: large | large |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses that it uses AI for timestamp selection, returns base64 images, and optionally saves to disk. With no annotations provided, this description carries the burden well. However, more details about performance or API calls could enhance transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, each providing distinct value: purpose, method, and output. Could be more concise by removing 'Optionally saves to disk' since it's covered in output_dir parameter.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers main aspects: video input, AI selection, number of screenshots, output format, and save behavior. However, no output schema means description could mention return format (array of base64 strings). Overall adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. Description adds context for 'focus' parameter but doesn't elaborate on 'resolution' enum meaning beyond schema. The 'output_dir' description adds context about fallback behavior, which adds value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it extracts screenshots from YouTube videos at important moments using AI. Distinguishes from siblings like 'extract_frames' by mentioning AI to find visually significant timestamps, but could be more specific about difference from 'extract_frames'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implies use for extracting key screenshots, but no explicit guidance on when to use vs siblings like 'extract_frames' or 'get_video_timestamps'. No mention of prerequisites (e.g., need ffmpeg).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Preview mode: Use AI to identify important moments in a YouTube video and return their timestamps WITHOUT extracting frames. Use this to preview what timestamps would be selected before committing to extraction.
| Name | Required | Description | Default |
|---|---|---|---|
| youtube_url | Yes | Full YouTube URL (youtube.com/watch?v=ID, youtu.be/ID, or youtube.com/shorts/ID) | |
| count | No | Number of timestamps to identify (1-20, default: 5) | |
| focus | No | Optional focus for timestamp selection (e.g., 'product demos', 'code examples', 'diagrams'). Default analyzes for general key moments. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It clearly states that it uses AI to identify timestamps and does not extract frames. However, it does not disclose other behavioral traits such as API rate limits, how the AI works, or constraints on video length/format.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, consisting of two sentences. The first sentence clearly defines the tool's function, and the second sentence explains its purpose relative to other tools. No unnecessary information is present.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (3 parameters, no output schema, no annotations), the description is fairly complete. It explains the tool's purpose and its relationship to extraction tools. However, it does not mention return format or behavior for invalid URLs, but the schema provides validation hints.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides descriptions for all parameters (100% coverage), so the description adds minimal value beyond the schema. However, the description does give context for the 'focus' parameter by providing examples like 'product demos' and 'code examples', which adds nuance beyond the schema's generic description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: to use AI to identify important moments in a YouTube video and return their timestamps without extracting frames. It distinguishes itself from sibling tools by emphasizing that it is a preview mode that does not extract frames, which sets it apart from extract_frames and extract_screenshots.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool: 'to preview what timestamps would be selected before committing to extraction.' However, it does not explicitly mention when not to use it or suggest alternatives, but the sibling list makes it clear that extraction tools exist for different purposes.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Summarize a YouTube video's content. Returns a text summary based on the specified detail level.
| Name | Required | Description | Default |
|---|---|---|---|
| youtube_url | Yes | Full YouTube URL (youtube.com/watch?v=ID, youtu.be/ID, or youtube.com/shorts/ID) | |
| detail_level | No | Level of detail: brief (2-3 sentences), medium (key points with timestamps), detailed (comprehensive breakdown) | medium |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must cover behavioral aspects. It mentions it returns a text summary based on detail level, but does not disclose processing time, input validation, or error handling. The behavior is straightforward but minimally described.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences: first states the core function, second explains output based on parameter. It is concise but could be more front-loaded about what the user gets. No fluff, but slightly vague on output format.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description should explain return format. It says 'returns a text summary' but not whether it's plain text, structured, or includes timestamps. With siblings like ask_about_video, more detail on output would help. Scores 3 as it covers basic purpose but lacks output specificity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description adds value by explaining the detail_level enum values (brief, medium, detailed) with concrete expectations like 'key points with timestamps', which is not in the schema. This extra context earns a 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it summarizes a YouTube video's content and returns a text summary based on a detail level. It distinguishes from siblings like ask_about_video (querying) and extract_frames (visual extraction), but could be more explicit about the summary format.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use or alternatives are provided. The description implies usage when a text summary is needed, but does not clarify when to choose this over ask_about_video or other tools. However, the enum options for detail_level give some usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tools are mostly distinct: ask_about_video and summarize_video both deal with content analysis but differ in question vs. summary. extract_frames and extract_screenshots have clear differences (given timestamps vs. AI-chosen moments). get_video_timestamps is a preview for extraction, reducing overlap. Minor confusion possible between ask_about_video and summarize_video.
All tool names use verb_* pattern with snake_case (ask_about_video, extract_frames, etc.), which is consistent. Some verbs are compound (ask_about), but the pattern is predictable and clear.
5 tools is appropriate for a YouTube MCP: they cover core operations (summarize, Q&A, frame extraction, screenshot extraction, timestamp preview). Not too few or too many.
The tool set covers main user needs: summarization, Q&A, and visual extraction with a preview step. Missing operations like searching videos or managing playlists, but those may be out of scope. The workflow from preview to extraction is well-supported.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Summarize YouTube videos or fetch transcripts. Pay-per-call via x402 (USDC on Base), no account.
Transcribe YouTube via Whisper. Summaries, chapters, semantic-search across your corpus.
Personal YouTube AI knowledge base powered by RAG. Query your subscribed YouTube channels.
Analyze images and videos with Gemini to get fast, reliable visual insights. Handle content from U…
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/PakmanGames/yt-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
