The yt-media-info MCP server extracts rich metadata, transcripts, and search results from 1800+ media sites (YouTube, Vimeo, Twitch, podcasts, etc.) using yt-dlp, without downloading any media files. It is designed for AI assistant integration.
Extract media metadata (extract_info): Retrieve title, description, duration, uploader, view counts, chapters, thumbnails, available subtitle languages, format summaries, playlist/channel info, and optionally the full raw yt-dlp info dict.
Fetch transcripts (get_transcript): Get timestamped subtitle segments or full concatenated transcript text, with support for multiple languages and both manual and auto-generated captions.
Search for media (search_media): Discover content on YouTube or Google Videos by query, returning up to 50 results with URL, title, duration, uploader, upload date, thumbnail, and view count.
Authentication support: Authenticate with site credentials (username/password) for restricted content, or upload Netscape-format cookie files via a web UI for member-only or age-restricted access. Optionally secure HTTP endpoints with a bearer API key.
Flexible deployment: Integrates via stdio (Claude Desktop), SSE (web clients/Claude Code), LiteLLM, or a direct REST API (POST /api) for testing.
Built-in prompts: Includes prompts like analyze_video and summarize_transcript to guide LLM interactions.
Click on "Deploy 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-media-info-mcp get metadata for 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.
Extract rich metadata, transcripts, and search from any yt-dlp-supported media URL — for Claude, Anthropic, and any MCP-compatible AI assistant.
yt-media-info MCP is a Model Context Protocol (MCP) server that lets AI assistants extract structured metadata from media URLs across 1800+ sites using yt-dlp — YouTube, Vimeo, Twitch, podcasts, and more. Given a URL (video, playlist, channel, podcast), it returns title, description, duration, chapters, subtitles/captions, formats, and statistics that models can reason over.
Built to sit alongside web-search tools as a media-enrichment step in an information-gathering pipeline. Works with Claude Desktop, Claude Code, LiteLLM, and any MCP client over stdio or SSE.
Compatible with any client that speaks the Model Context Protocol:
Claude Desktop — via stdio transport
Claude Code — via SSE transport
LiteLLM — as an mcp model in the gateway config
Open WebUI and any MCP-aware agent framework
Custom apps — via the MCP SDK (SSE) or the plain JSON POST /api shortcut
Related MCP server: YouTube Content Extractor MCP
Extract rich metadata from any yt-dlp-supported URL (YouTube, Vimeo, Twitch, and ~1800 more sites)
Fetch transcripts with timestamps or as full text
Search for media across supported platforms (supplementary discovery)
Curated + raw output: focused summary at the top level, full yt-dlp info dict nested under raw
Snake_case fields, ISO 8601 dates — matches yt-dlp's native format
Optional two-layer auth: yt-dlp site credentials + bearer API key for your own endpoints
Multiple transport options: stdio for Claude Desktop, SSE for web clients
Direct API endpoint (POST /api) for quick testing without MCP protocol
Persistent Python backend: no cold-start per call (imports yt-dlp once at startup)
RAG over video — pull a video's transcript and metadata into a retrieval pipeline so an LLM can answer questions about the content without watching it.
Summarize lectures, talks, and podcasts — feed the transcript to a model for key points, notable quotes, and takeaways (see the summarize_transcript prompt).
Podcast & lecture indexing — extract titles, descriptions, chapters, and durations to build searchable catalogs of audio/video content.
Accessibility via captions — retrieve subtitles (manual or auto-generated) in any available language for transcription and translation workflows.
Channel & playlist research — expand a playlist or channel into structured per-video metadata for analysis, deduplication, or ranking.
Media enrichment in search pipelines — pair with a web-search tool: discover candidate URLs, then enrich each one with full metadata and transcripts before summarization.
Content discovery — use search_media to find videos on YouTube or Google Video by query, then drill into the ones that matter.
Node.js 18+
Python 3.12+ (for standalone development)
Docker + Docker Compose (for recommended deployment)
# Clone the repository
cd yt-media-info-mcp
# Install Node dependencies
npm install
# Build the Python service Docker image
docker compose build yt-dlp-serviceIf you want to run the Python service directly:
cd service
pip install -r requirements.txt
uvicorn main:app --host 0.0.0.0 --port 8000Then in another terminal:
YT_MEDIA_INFO_SERVICE_URL=http://localhost:8000 npm startVariable | Description | Default |
| Use SSE transport (vs stdio) |
|
| HTTP server port (SSE mode) |
|
| HTTP server host (SSE mode) |
|
| URL of the Python yt-dlp service |
|
| Optional bearer API key for HTTP endpoints | (empty = no auth) |
| Default username for yt-dlp site auth | (empty) |
| Default password for yt-dlp site auth | (empty) |
| Winston log level (error, warn, info, debug) |
|
Copy .env.example to .env and customize. .env is gitignored — use .env.local for per-machine secrets not tracked by git.
{
"mcpServers": {
"yt-dlp": {
"command": "node",
"args": ["/path/to/yt-media-info-mcp/src/index.js"],
"env": {
"ENABLE_SSE": "0"
}
}
}
}{
"mcpServers": {
"yt-dlp": {
"type": "sse",
"url": "http://localhost:9423/sse"
}
}
}# config.yaml
model_list:
- model_name: yt-dlp
litellm_params:
model: mcp
mcp_servers:
yt-dlp:
transport: sse
url: http://host.docker.internal:9423/sseThe POST /api endpoint bypasses the MCP protocol and returns results directly:
# Extract info
curl -X POST http://localhost:9423/api \
-H "Content-Type: application/json" \
-d '{
"tool": "extract_info",
"args": {
"url": "https://www.youtube.com/watch?v=YE7VzlLtp-4"
}
}'
# Get transcript
curl -X POST http://localhost:9423/api \
-H "Content-Type: application/json" \
-d '{
"tool": "get_transcript",
"args": {
"url": "https://www.youtube.com/watch?v=YE7VzlLtp-4",
"language": "en"
}
}'
# Search media
curl -X POST http://localhost:9423/api \
-H "Content-Type: application/json" \
-d '{
"tool": "search_media",
"args": {
"query": "python tutorial",
"limit": 5
}
}'The server exposes standard MCP SSE endpoints:
Endpoint | Purpose |
| SSE connection stream (MCP transport) |
| Send MCP JSON-RPC messages to the server |
| Direct JSON API (bypasses MCP) |
| Health check |
// Connect via MCP SDK
import { Client } from '@modelcontextprotocol/sdk/client/index.js';
import { SSEClientTransport } from '@modelcontextprotocol/sdk/client/sse.js';
const transport = new SSEClientTransport(new URL('http://localhost:9423/sse'));
const client = new Client({ name: 'web-app', version: '1.0' });
await client.connect(transport);
const result = await client.request(
{ method: 'tools/call', params: { name: 'extract_info', arguments: { url: 'https://www.youtube.com/watch?v=YE7VzlLtp-4' } } },
resultSchema
);docker compose up -d # start both services
docker compose logs -f # tail logs
docker compose down # stop
docker compose build # rebuild after changesThe yt-dlp-service container is persistent and stays warm. The yt-media-info-mcp container waits for the health check on the Python service before accepting connections.
Extracts rich metadata from a media URL.
Parameters:
Parameter | Type | Description | Default |
| string | Media URL to extract information from | (required) |
| boolean | Include the full yt-dlp sanitized info_dict under |
|
| string? | Username for site authentication |
|
| string? | Password for site authentication |
|
Output: Curated metadata (title, description, duration, uploader, statistics, chapters, thumbnails, formats summary, subtitles available, playlist info) + optional raw info dict.
Fetches subtitles or transcript text for a media URL.
Parameters:
Parameter | Type | Description | Default |
| string | Media URL to fetch transcript from | (required) |
| string | Preferred subtitle language code |
|
| boolean | Include timestamp segments in response |
|
| string? | Username for site authentication |
|
| string? | Password for site authentication |
|
Output: Language, duration, subtitle segments (with timestamps if requested), and concatenated full_text.
Supplementary discovery tool. Searches for media using yt-dlp's search prefixes (e.g. ytsearch:). This is a companion to general-purpose web search — it finds candidate URLs for further enrichment.
Parameters:
Parameter | Type | Description | Default |
| string | Search query | (required) |
| integer | Maximum number of results (max 50) |
|
| string | Platform to search. Supported: |
|
Output: Results array with url, title, duration_seconds, uploader, upload_date, thumbnail, view_count.
analyze_video: Analyze a video/media item from its available metadata (title, description, duration, uploader, categories, optional transcript summary).
summarize_transcript: Summarize a video transcript to extract key points, notable quotes, and practical takeaways.
snake_case field names (matches yt-dlp's native format)
ISO 8601 date strings (e.g. "2024-01-15" for upload_date, "2024-01-15T14:30:00Z" for timestamps)
Best-effort error handling: complete failures return an error response; missing fields are null; playlist entries that fail are collected in a failures array
When running in SSE mode, the server provides a web-based cookie upload form at http://<host>:<port>/ (default http://localhost:9423/) for uploading Netscape-format cookie files.
Export cookies from your browser using yt-dlp:
yt-dlp --cookies-from-browser chrome --cookies cookies.txtOr use a browser extension like Get cookies.txt LOCALLY.
Open the form at http://localhost:9423/ in your browser.
Upload the cookies.txt file — the form validates the file format, writes it atomically to the shared Docker volume at /data/cookies.txt, and displays parsed cookie info (domains, count, earliest expiry).
Delete cookies via the form's delete button when needed.
Method | Path | Description |
|
| HTML upload form |
|
| Upload a cookies.txt file (multipart/form-data, field name |
|
| Delete the cookie file |
All endpoints are protected by the same YT_MEDIA_INFO_API_KEY bearer auth as the other HTTP endpoints (when configured).
The file must:
Start with # Netscape HTTP Cookie File
Be under 1 MB
Use tab-separated Netscape cookie format
If you have the cookie-bot sidecar running (opt-in via docker compose --profile cookies up -d), it will periodically refresh cookies from the shared volume. The web upload form is a convenient way to seed the initial cookie file — the cookie-bot then takes over automated refreshes.
Note: The cookie-bot's automated refresh will overwrite a manually uploaded file. Use the web form for initial seeding, then let the bot handle refreshes.
This server does NOT download media files. It is a metadata enrichment and transcript extraction tool designed to work alongside other search and retrieval tools. No ffmpeg is required.
npm run dev # nodemon auto-restart
npm run lint # ESLint
npm run lint:fix # ESLint auto-fixThis project is licensed under the MIT License.
Extract rich metadata from a media URL (title, description, duration, formats, chapters, subtitles, statistics, and more)
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | Media URL to extract information from | |
| password | No | Password for site authentication | |
| username | No | Username for site authentication | |
| include_raw | No | Include the full yt-dlp info_dict under a "raw" field |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries the full burden. It implies a read operation ('Extract') and lists metadata fields, but does not disclose authentication requirements, rate limits, error handling, or limitations. It mentions 'and more' vaguely.
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?
Single sentence, front-loaded with the operation, and includes a representative list. No unnecessary words or repetition.
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 4 parameters, no output schema, no annotations, and two siblings, the description gives a good overview but lacks usage context, return format details, and potential constraints (e.g., auth, rate limits). Adequate but incomplete.
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 each parameter already has a description. The tool description adds an overview of the extracted metadata but does not elaborate on parameter usage beyond the schema. 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?
The description clearly states the action ('Extract') and specific resource ('rich metadata from a media URL'), including a list of extracted items (title, description, duration, etc.), which distinguishes it from siblings get_transcript and search_media.
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 guidance on when to use this tool versus alternatives. No mention of prerequisites, context, or exclusions. Agent must infer usage from the description alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch subtitles or transcript text for a media URL, optionally with timestamp segments
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | Media URL to fetch transcript from | |
| language | No | Preferred subtitle language code (e.g. "en", "es") | en |
| password | No | Password for site authentication | |
| username | No | Username for site authentication | |
| timestamps | No | Include timestamp segments in the response |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions optional timestamps but does not describe output format, error handling, rate limits, authentication requirements (despite username/password params), or any side effects. The behavior is only superficially 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 a single sentence with no wasted words. It is front-loaded with the core action ('Fetch subtitles or transcript text') and mentions the key optional feature. Every word serves a purpose.
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 absence of annotations and output schema, and the presence of authentication-related parameters (username, password), the description should provide more context on return values, error scenarios, and authentication flow. As is, it leaves significant gaps for a non-trivial tool with 5 parameters.
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 the schema already documents all parameters adequately. The description adds 'optionally with timestamp segments' which corresponds to the timestamps parameter but does not enhance schema information. Baseline score 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?
Description clearly states the tool fetches subtitles or transcript text from a media URL with optional timestamps. It uses a specific verb ('Fetch') and resource ('subtitles or transcript text'), and distinguishes itself from siblings like 'extract_info' (metadata extraction) and 'search_media' (search).
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 guidance on when to use this tool versus alternatives. The description does not mention when not to use it, nor does it reference sibling tools or provide context for preferred usage scenarios. The agent must infer use from the description alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search for media across supported platforms (YouTube, etc.) using yt-dlp search. This is a supplementary discovery tool meant to complement web search.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of results (max 50) | |
| query | Yes | Search query for media discovery | |
| platform | No | Platform to search. youtube → ytsearch:, google_videos → gvsearch: | youtube |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It states the tool uses yt-dlp search, which suggests a read-only operation, but does not explicitly confirm it is non-destructive or mention any side effects, permission requirements, or rate limits. Adequate but could be more explicit.
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?
Two concise sentences that immediately convey the tool's purpose, scope, and supplementary nature. No redundant words; every sentence adds value.
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?
The description explains the tool's purpose and method, but lacks details about output structure or how results relate to sibling tools (extract_info, get_transcript). Without an output schema, the description should guide the agent on what to expect from results. Adequate but not fully complete.
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% with each parameter fully described. The tool description adds context about yt-dlp and platform mapping (e.g., 'youtube → ytsearch:'), but the schema already covers the enum values. Thus, the description adds marginal value beyond the schema, meeting the baseline.
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 explicitly states the verb 'Search' and resource 'media', specifies supported platforms (YouTube, etc.) and the underlying technology (yt-dlp), and clarifies its role as a supplementary discovery tool, which clearly distinguishes it from siblings like extract_info and get_transcript.
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 mentions it is a 'supplementary discovery tool meant to complement web search', implying when to use it for media discovery, but does not explicitly state when not to use it or name alternatives. It provides implied context but lacks clear exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v1.0.0extract_infoget_transcriptsearch_mediaScored across 3 tools
Each tool has a distinct purpose: metadata extraction, transcript retrieval, and media search. No overlap in functionality.
All tool names follow a consistent verb_noun pattern (extract_info, get_transcript, search_media) using lowercase snake_case.
Three tools is appropriate for a focused media info server, covering core operations without excess.
The tool set covers the main use cases for media information: metadata extraction, transcript fetching, and search. No obvious gaps for its stated purpose.
MCP server for RiverScript, an AI transcription platform - fetches transcripts shared via a link.
An MCP server that gives any LLM or agent clean YouTube transcripts on demand: a single video, a whole channel, or a playlist, plus AI cleanup of auto-generated captions. API-key auth, credit-based, same backend as the public v1 API. Get a free API key with 25 free credits at youtubetranscriptdownload.com/account.
YouTube transcripts, search, channel browsing, and playlists for AI agents via MCP.
Any social-video URL → transcript, metadata, frames, OCR, summary, search, Q&A. MCP server + x402.
