Skip to main content
Glama
AgentX-ai

YouTube DLP MCP Server

by AgentX-ai
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

YouTube DLP MCP Server

Website Discord

🎬 A Model Context Protocol (MCP) server that lets your AI interact with YouTube videos - extract video information, subtitles, and top comments without downloading.

✨ Features

  • 📹 Extract Video Info - Get comprehensive metadata (title, views, likes, description, etc.)

  • 📝 Extract Subtitles - Download manual subtitles and auto-generated captions

  • 💬 Extract Comments - Get top comments sorted by likes with creator badges

  • 🌐 Proxy Support - Works with HTTP/HTTPS/SOCKS proxies

  • 🚀 Fast & Async - Non-blocking operations using asyncio

  • 🔧 Easy Integration - Standard MCP protocol for AI assistants

Related MCP server: mcp-server-youtube

🚀 Quick Start

Install with uvx (Recommended)

uvx youtube-dlp-server

Install with pip

pip install youtube-dlp-server
youtube-dlp-server

Install from source

git clone <repository-url>
cd youtube-dlp-server
pip install -e .
python -m youtube_dlp_server

🛠️ Usage

Available Tools

1. get-video-info

Extract comprehensive video metadata:

{
  "name": "get-video-info",
  "arguments": {
    "url": "https://www.youtube.com/watch?v=dQw4w9WgXcQ"
  }
}

2. get-video-subtitles

Extract subtitles and captions:

{
  "name": "get-video-subtitles",
  "arguments": {
    "url": "https://www.youtube.com/watch?v=dQw4w9WgXcQ",
    "languages": ["en", "es"],
    "include_auto_captions": true
  }
}

3. get-top-comments

Get top comments (max 20, default 10):

{
  "name": "get-top-comments",
  "arguments": {
    "url": "https://www.youtube.com/watch?v=dQw4w9WgXcQ",
    "count": 10
  }
}

Proxy Configuration

Set the PROXY_URL environment variable:

# HTTP/HTTPS proxy
export PROXY_URL="http://proxy.example.com:8080"

# SOCKS proxy with auth
export PROXY_URL="socks5://user:pass@127.0.0.1:1080/"

# Run with proxy
youtube-dlp-server

🧪 Testing

With MCP Inspector

npx @modelcontextprotocol/inspector youtube-dlp-server

Manual Testing

python -c "
import asyncio
from youtube_dlp_server.helper import extract_video_info
async def test():
    info = await extract_video_info('https://www.youtube.com/watch?v=dQw4w9WgXcQ')
    print(f'✅ Video: {info[\"title\"]}')
asyncio.run(test())
"

📋 Requirements

  • Python 3.11+

  • yt-dlp for YouTube processing

  • MCP framework for AI integration

🤝 Contributing

  1. Fork the repository

  2. Create a feature branch

  3. Make your changes

  4. Add tests

  5. Submit a pull request

📄 License

MIT License - see LICENSE file for details.

🔗 Links

Made with ❤️ for the AI community

Available Tools

3 tools
get-top-commentsA

Extract top comments from a YouTube video (sorted by likes)

ParametersJSON Schema
NameRequiredDescriptionDefault
urlYesYouTube video URL to extract comments from
countNoNumber of top comments to extract (default: 10, maximum: 20)

TDQS

A3.7/5.0
Behavior3/5

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

With no annotations provided, the description carries the full behavioral disclosure burden. It adds meaningful behavior by stating comments are sorted by likes, but it does not mention the return format, pagination, failure cases, or that it only returns top comments rather than all comments.

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 one efficient sentence with no filler. The core action, resource, and sorting behavior are all front-loaded, making it easy for an agent to scan and understand quickly.

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 tool is simple and the description plus schema cover the required URL and optional count. Still, there is no output schema and no annotation context, so the agent is left without explicit indication of what the response shape looks like or which sibling to prefer in related video requests.

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%, with both 'url' and 'count' already described including defaults and bounds. The description's 'sorted by likes' further clarifies what 'top' means but does not add meaningful parameter-level semantics beyond the schema.

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 names a specific action ('Extract'), a clear resource ('top comments from a YouTube video'), and a distinguishing qualifier ('sorted by likes'). It is immediately distinguishable from siblings like get-video-info and get-video-subtitles without needing to inspect their schemas.

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 the tool: when the agent needs the most-liked comments on a YouTube video. However, it gives no explicit guidance about when not to use it or which sibling should be selected instead for metadata or transcription needs.

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

get-video-infoB

Extract detailed information from a YouTube video URL without downloading

ParametersJSON Schema
NameRequiredDescriptionDefault
urlYesYouTube video URL to extract information from

TDQS

B3.3/5.0
Behavior3/5

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

With no annotations, the description carries the full transparency burden. It conveys a meaningful behavioral trait — the operation extracts metadata rather than downloading the video — but it does not disclose that a network request is made, what fields are returned, or potential failure conditions. Some context is provided, but not the full picture.

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 a single front-loaded, ten-word sentence that contains both the core action and the key constraint. Nothing is wasted; every phrase contributes to understanding what the tool does.

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?

For a low-complexity, one-parameter tool the description is sufficient to make a valid call (provide a YouTube URL). However, with no output schema and no annotation, it does not specify what 'detailed information' includes, which leaves the agent without a way to predict the response or distinguish it confidently from sibling capabilities.

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 schema already documents the single url parameter fully. The description restates the URL concept without adding format constraints, accepted URL variants, or other semantic detail, so it adds little on top of the schema — the baseline 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 uses a specific verb ('Extract') and identifies both the target resource (a YouTube video URL) and the operation outcome ('detailed information'), and adds the useful qualifier 'without downloading.' It falls short of a 5 because it does not distinguish itself from the sibling tools get-video-subtitles and get-top-comments, and 'detailed information' is left underspecified.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no explicit guidance about when to use this tool versus get-video-subtitles or get-top-comments, and no when-not-to-use conditions. 'Without downloading' only implies a boundary; it does not state selection criteria or alternatives.

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

get-video-subtitlesB

Extract subtitles and captions from a YouTube video

ParametersJSON Schema
NameRequiredDescriptionDefault
urlYesYouTube video URL to extract subtitles from
languagesNoList of language codes to extract (e.g., ['en', 'es']). If not provided, all available languages will be extracted.
include_auto_captionsNoWhether to include auto-generated captions (default: true)

TDQS

B3.3/5.0
Behavior2/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure, but it only states the basic action. It does not mention whether authentication is needed, what the output format looks like, whether auto-generated captions are handled specially, or any other relevant behavior beyond what the schema already conveys.

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 a single, direct sentence with no fluff. It front-loads the core purpose and wastes no words, which is ideal for quick comprehension.

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 tool is moderately simple and the schema covers all parameters, but there is no output schema and no annotations, so return format and behavioral expectations are unclear. The description alone is adequate for basic understanding but leaves gaps around what the extraction result actually looks like.

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 schema fully documents all three parameters. The description adds no additional semantic context beyond the schema, so it meets the baseline without further enhancement.

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 uses a specific verb ('Extract') and resource ('subtitles and captions from a YouTube video'), making the tool's function immediately clear. It is naturally distinguished from siblings like get-video-info and get-top-comments by the explicit focus on subtitle/caption extraction.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no guidance about when to use this tool versus alternatives, such as get-video-info or get-top-comments. The usage context is only implied by the tool name and description; no explicit exclusions or alternative routing are provided.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

  1. 3 tool updatesv0.1.0
    • First observedget-top-comments
    • First observedget-video-info
    • First observedget-video-subtitles
Deploy Server
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A3.6/5.0

Scored across 3 tools

Disambiguation5/5

Each tool targets a clearly distinct data type: video metadata, subtitles, and comments. There is no overlap in purpose or expected output.

Naming Consistency5/5

All three tool names follow the exact same 'get-video-<detail>' pattern with consistent hyphenated lowercase naming. The convention is uniform and predictable.

Tool Count4/5

Three tools is on the lower end but each one earns its place for a focused YouTube metadata extraction server. The scope is narrow yet coherent.

Completeness2/5

Despite the server name referencing 'DLP' (download), there is no download or format-listing tool. The set only covers metadata, subtitles, and comments, leaving a significant gap for a server that implies downloading capability.

Maintenance

ActivityInactive
ResponsivenessUnresponsive

Resources

Related MCP Connectors

Related MCP Servers