Extracts metadata and downloads videos from Facebook, with fallback scraping for reliable access.
Extracts metadata and downloads videos from TikTok, including title, description, uploader, duration, and direct MP4 link.
Extracts metadata and downloads videos from Vimeo, including title, description, uploader, duration, and direct MP4 link.
Extracts metadata and downloads videos from YouTube, including title, description, uploader, duration, and direct MP4 link.
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-dlp get metadata from https://youtu.be/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.
Standalone MCP server for extracting metadata and downloading videos (TikTok, YouTube, etc.) via yt-dlp.
Extract video metadata (title, description, uploader, duration)
Get direct .mp4 link without downloading
Download videos locally to a downloads folder (now generates both universal MP4 and separate MP3 audio file)
Clear downloads cache to free up disk space
Support for multiple platforms (TikTok, YouTube, Facebook, Vimeo, etc.)
Related MCP server: MCP YouTube-DLP
# Project initialization (already done)
uv init
# Install dependencies (already done)
uv add "mcp[cli]" yt-dlpuv run server.pyThe server runs in stdio mode and is ready to be used by any MCP client.
Add to your ~/Library/Application Support/Code/User/globalStorage/saoudrizwan.claude-dev/settings/cline_mcp_settings.json an entry to "mcpServers" element:
the above path is for macos, with cline installed as VS code extension ! you'll have to check for linux ou windows using the cline mcp configuration management interface, it opens the file for you ! with "Configure MCP Servers" Button !
{
"mcpServers": {
"other-mcp-server": { },
"yt-dlp": {
"command": "uv",
"args": ["run", "--directory", "<your_path>/yt-dlp-mcp", "server.py"]
}
}
}don't use ~ in , else cline won't find the file, use true root path !
Add to your ~/.opencode/mcp.json:
{
"servers": {
"yt-dlp": {
"command": "uv",
"args": ["run", "--directory", "<your_path>/yt-dlp-mcp", "server.py"]
}
}
}Add to your claude_desktop_config.json:
{
"mcpServers": {
"yt-dlp": {
"command": "uv",
"args": ["run", "--directory", "<your_path>/yt-dlp-mcp", "server.py"]
}
}
}Add to your ~/.config/zed/settings.json:
{
"mcp": {
"servers": {
"yt-dlp": {
"command": "uv",
"args": ["run", "--directory", "<your_path>/yt-dlp-mcp", "server.py"]
}
}
}
}Add to your ~/.cursor/mcp.json:
{
"mcpServers": {
"yt-dlp": {
"command": "uv",
"args": ["run", "--directory", "<your_path>/yt-dlp-mcp", "server.py"]
}
}
}Extracts metadata and direct link from a video. Supports Facebook via lightweight regex and fb-video scraper as fallback.
extract_video_info(url="https://www.tiktok.com/@username/video/123456789")Parameters:
url (str): The URL of the video to extract
Returns:
title : Video title
description : Video description
uploader : Uploader name
duration : Duration in seconds
url : Direct video link (.mp4)
webpage_url : Original page URL
thumbnail : Thumbnail URL
error : Error message if extraction failed
source : Scraper source (if using Facebook fallbacks)
Downloads a video and generates both a universal MP4 (H.264/AAC/FastStart) and a separate MP3 audio file to the local downloads folder.
download_video(url="https://www.tiktok.com/@username/video/123456789")Parameters:
url (str): The URL of the video to download
Returns:
success : Boolean indicating success
title : Video title
filename_mp4 : Local MP4 filename
filename_mp3 : Local MP3 filename
local_path_mp4 : Absolute path to the downloaded MP4 file
local_path_mp3 : Absolute path to the downloaded MP3 file
message : Status message
error : Error message if download failed
Clears all files from the downloads folder.
clear_downloads()Returns:
success : Boolean indicating success
deleted_count : Number of files deleted
error : Error message if operation failed
uv add --upgrade yt-dlpPython 3.10+
uv (Python package manager)
ffmpeg (optional, for video processing)
Clears all files from the downloads folder.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
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. It states the action ('clears all files') and scope ('downloads folder'), but it does not disclose whether the deletion is permanent, whether files go to trash, if any confirmation is required, or what the result/return value looks like. For a destructive operation, this is a significant gap.
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?
A single, front-loaded sentence contains the entire definition with no filler or repetition. Every word adds meaning and the structure is ideal for quick scanning.
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 zero-parameter tool, the description covers the basic what and where, which is minimally viable. However, it lacks critical context for a destructive operation: whether deletion is irreversible, what 'downloads folder' refers to (e.g., system default vs. app-specific), and what happens after execution. With no annotations and no output schema, this leaves the agent without enough safety-relevant information.
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 tool has zero parameters, so there are no parameter semantics to explain. The description's clarity about the action and target makes the lack of params expected and non-confusing. Baseline for zero-parameter tools is 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 uses a specific verb ('clears') and a specific resource ('files from the downloads folder'). It is immediately distinguishable from the sibling tools extract_video_info and download_video, which are about video retrieval and saving, not deletion.
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 tool's purpose is self-evident and clearly disjoint from the siblings, so an agent can infer when to use it. However, the description gives no explicit when-to-use guidance, no mention of alternatives, and no warning that clearing is destructive and should be used only when intended.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Downloads a video from url extracted from the page and generates both a universal MP4 (H.264/AAC/FastStart) and a separate MP3 audio file.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | The URL of the page of the video to download |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of explaining behavior. It does so by disclosing that two outputs are generated, including the MP4 codecs (H.264/AAC) and FastStart flag. It does not mention return values, save location, or failure conditions, but the main side effect is clearly 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 filler. Key information is front-loaded (downloads a video) and the output formats/codecs are added efficiently.
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 tool has only one required parameter, no enums, and no nested objects, so complexity is low. The description is sufficient for an agent to know what to pass and what outputs to expect, though details about return values or download location would make it more 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?
The schema already documents the single url parameter with 100% coverage. The description adds a slight nuance by referring to a URL 'extracted from the page,' but this mostly restates the schema's existing 'URL of the page' wording.
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?
States a concrete action ('Downloads') and a specific resource (video from a page URL), then names the exact output artifacts: universal MP4 and separate MP3. This clearly distinguishes it from extract_video_info, which is about inspecting video metadata rather than downloading 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?
The intended use case is obvious: call this tool when a video should be downloaded and converted to MP4/MP3. It does not explicitly name alternatives or exclusions, but the sibling tool names make the decision reasonably clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Extracts metadata and direct link from a video page from youtube, tiktok, facebook
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | The URL of the page for getting info about the video to extract |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral disclosure burden. It does communicate the core behavior: a read-only extraction of metadata and a direct link from supported video pages. However, it does not mention what happens with unsupported URLs, error behavior, return format, or whether any network-side side effects occur.
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?
A single, direct sentence conveys the verb, resource, scope, and supported platforms without unnecessary words. Every element earns its place, and the core purpose is front-loaded.
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?
This is a low-complexity tool with one required parameter and no output schema. The description tells an agent what it will get (metadata and direct link) and which sources are supported. It lacks detailed return fields or failure behavior, but for a simple one-URL tool it is largely sufficient.
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 input schema already documents the single parameter well, with the description stating it is the URL of the page for getting info about the video to extract. Schema coverage is 100%, so the description does not add much beyond confirming the platform scope. Baseline 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 names a specific verb ('extracts'), a specific resource ('metadata and direct link'), and explicitly scopes supported platforms (youtube, tiktok, facebook). This clearly distinguishes the tool from the sibling download_video: one extracts info, the other downloads video files.
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 implies this tool is for retrieving metadata and direct links rather than downloading videos, but it never explicitly says 'use download_video when you want the video file' or provides exclusion criteria. An agent can infer the intended use, but the guidance is not spelled out.
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.
v0.1.0clear_downloadsdownload_videoextract_video_infoScored across 3 tools
Each tool has a clearly distinct role: extraction, downloading, and cleanup. There is no overlap or ambiguity between them.
All tool names follow a consistent verb_noun snake_case pattern: extract_video_info, download_video, clear_downloads. The naming is predictable and uniform.
Three tools is a well-scoped set for a focused yt-dlp workflow: extract metadata, download media, and clear storage. Each tool has a clear purpose and none feel redundant.
The core workflow of extracting video info and downloading video/audio is covered, with cleanup included. Minor gaps exist such as no option to download video-only or audio-only, and no selective file deletion, but these do not severely hinder the primary use case.
Download YouTube, TikTok, Vimeo, SoundCloud and 6 more platforms from any MCP AI chatbot.
Any video URL to LLM-ready transcript. ASR built in, no captions needed. TikTok, X, TED and more.
Any social-video URL → transcript, metadata, frames, OCR, summary, search, Q&A. MCP server + x402.
Turn a TikTok/Instagram/YouTube link into text for your AI: metadata, transcript and image OCR.
