ReClip's MCP server lets an agent inspect, download, and clip media from 1000+ yt-dlp-supported sites, writing files locally.
inspect_media (read-only) — fetch normalized metadata and available formats for a public URL without downloading.
download_media — download a full authorized item locally as MP4 or MP3, with quality (e.g. 1080p, 192k, best); requires confirm_authorized.
download_clip — download only an authorized time range (SS, MM:SS, HH:MM:SS.000) as MP4 or MP3 without storing the full source; requires confirm_authorized.
list_supported_sites — list or search extractor names from the locally installed yt-dlp (paged via limit, filtered by query).
Note: all tools are open-world (network access to the media sites); downloads can consume significant bandwidth/storage.
Enables downloading videos, extracting audio, and creating clips from Dailymotion.
Enables downloading videos, extracting audio, and creating clips from Facebook.
Enables downloading videos, extracting audio, and creating clips from Instagram.
Enables downloading videos, extracting audio, and creating clips from Loom.
Enables downloading videos, extracting audio, and creating clips from Pinterest.
Enables downloading videos, extracting audio, and creating clips from Reddit.
Enables downloading audio, extracting audio, and creating clips from SoundCloud.
Enables downloading videos, extracting audio, and creating clips from Threads.
Enables downloading videos, extracting audio, and creating clips from TikTok.
Enables downloading videos, extracting audio, and creating clips from Tumblr.
Enables downloading videos, extracting audio, and creating clips from Twitch.
Enables downloading videos, extracting audio, and creating clips from Vimeo.
Enables downloading videos, extracting audio, and creating clips from YouTube.
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., "@io.github.yagyaanshK/reclip Clip this video from 2:00 to 2:30 as MP3."
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 self-hosted, open-source video and audio downloader with a clean web UI. Paste links from YouTube, TikTok, Instagram, Twitter/X, and 1000+ other sites — download as MP4 or MP3.
https://github.com/user-attachments/assets/419d3e50-c933-444b-8cab-a9724986ba05
Download videos from 1000+ supported sites (via yt-dlp)
MP4 video or MP3 audio extraction
Quality/resolution picker
Download precise clips by start/end time without first storing the full source
Bulk downloads — paste multiple URLs at once
Automatic URL deduplication
Clean, responsive UI — no frameworks, no build step
Native Desktop Apps — zero-install standalone executables for Windows, macOS, and Linux.
Intelligent Filename Generation — extracts and formats metadata gracefully (Artist - Track.mp3 or Channel - Title.mp4).
Local-first operation — downloads run on the user's own machine and network connection.
Automated Build Pipeline — GitHub Actions automatically compiles and publishes new executables upon every version tag push.
Related MCP server: yt-dlp-mcp-server
You don't need to install Python or use the terminal. Download the pre-built standalone executable for your operating system:
🪟 Windows: ReClip.exe
🍎 macOS: ReClip-macos.dmg
🐧 Linux: ReClip
Note: The native apps contain a bundled server and PyWebView browser. Simply open the app and it will launch right in its own native window!
Keeps itself working when YouTube changes. The app ships with a copy of yt-dlp but does not depend on it staying current: once a day, and whenever a download fails in a way a newer yt-dlp usually fixes (HTTP 403, "sign in to confirm", player changes), ReClip fetches the latest yt-dlp from PyPI into your user profile, verifies its checksum, and retries. You can also click Check for updates at the bottom of the window. Nothing else is downloaded or sent anywhere.
YouTube needs a JavaScript runtime. yt-dlp solves YouTube's player challenges with Deno (recommended) or Node.js. Install one and restart ReClip if you see "YouTube needs a JavaScript runtime".
Free code signing provided by SignPath.io, certificate by SignPath Foundation.
Windows releases of ReClip.exe are built on GitHub Actions and Authenticode-signed with a SignPath Foundation certificate. The publisher shown by Windows is SignPath Foundation. Signing runs only for tagged releases; the full pipeline lives in .github/workflows/build.yml and the artifact configuration in .signpath/artifact-configuration.xml.
Team roles
Role | Member |
Committers and reviewers | |
Approvers |
Privacy policy
This program will not transfer any information to other networked systems unless specifically requested by the user or the person installing or operating it. The only automatic network access is a daily check of pypi.org for a newer yt-dlp release (see "Keeps itself working when YouTube changes" above); the request carries no user data. ReClip only contacts the media sites you paste URLs for, and the desktop app runs entirely on your own computer.
git clone https://github.com/yagyaanshK/reclip.git
cd reclipOn Windows:
Double-click start_windows.bat.
On Mac / Linux:
./reclip.shOpen http://localhost:8899 in your browser.
To manually compile ReClip into a standalone executable:
Windows: Run build_windows.bat -> Output in dist/
Mac / Linux: Run ./build_unix.sh -> Output in dist/
Or with Docker:
docker build -t reclip . && docker run -p 8899:8899 reclipPaste one or more video URLs into the input box
Choose MP4 (video) or MP3 (audio)
Click Fetch to load video info and thumbnails
Select quality/resolution if available
Optionally enable Clip and enter start/end times as SS, MM:SS, or HH:MM:SS.000
Click Download on individual videos, or Download All
ReClip also exposes a structured local CLI for shell scripts and AI agents. Install it in a Python 3.10+ environment with uv:
uv tool install reclip-mcpThen run:
reclip inspect "https://example.com/media" --json
reclip download "https://example.com/media" --format mp4 --quality 1080p --output downloads --json
reclip clip "https://example.com/media" --start 01:20:15.500 --end 01:25:00 --format mp3 --output downloads --json
reclip sites --jsonAll JSON responses contain an ok field. Failures include a stable machine-readable error code and a human-readable message. Downloads occur locally and return the absolute output path, filename, byte size, format, source URL, and clip range.
Configure an MCP host to install and start ReClip over stdio without cloning the repository:
{
"mcpServers": {
"reclip": {
"command": "uvx",
"args": ["reclip-mcp"],
"env": {
"RECLIP_MCP_DOWNLOAD_DIR": "/absolute/path/to/downloads"
}
}
}
}Use the absolute path to uvx if the MCP host does not inherit your shell PATH. The server exposes inspect_media, download_media, download_clip, and list_supported_sites. Download tools require explicit user authorization and can write only to RECLIP_MCP_DOWNLOAD_DIR, which defaults to ~/Downloads/ReClip.
For development from a checkout, run python -m pip install . and configure the host to execute python -m reclip_mcp.
Anything yt-dlp supports, including:
YouTube, TikTok, Instagram, Twitter/X, Reddit, Facebook, Vimeo, Twitch, Dailymotion, SoundCloud, Loom, Streamable, Pinterest, Tumblr, Threads, LinkedIn, and many more.
Backend: Python + Flask
Frontend: Vanilla HTML/CSS/JS (single file, no build step)
Dependencies: flask, yt-dlp, yt-dlp-ejs, pycryptodomex, pywebview, pyinstaller, imageio-ffmpeg
This tool is intended for personal use only. Please respect copyright laws and the terms of service of the platforms you download from. The developers are not responsible for any misuse of this tool.
Download only a precise authorized time range locally as MP4 video or MP3 audio. Timestamps support SS, MM:SS, or HH:MM:SS.000.
| Name | Required | Description | Default |
|---|---|---|---|
| end | Yes | Exclusive clip end: SS, MM:SS, or HH:MM:SS.000 | |
| url | Yes | Public HTTP or HTTPS media page URL | |
| start | Yes | Inclusive clip start: SS, MM:SS, or HH:MM:SS.000 | |
| quality | No | 'best', a video height such as 1080p, or an audio bitrate such as 192k | best |
| media_format | No | Output media format | mp4 |
| confirm_authorized | No | True only after the user confirms they may download this media |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish that this is a non-read-only, non-destructive operation. The description adds that output is saved locally and that authorization is involved, which is useful, but it does not explain what happens when confirm_authorized is false or whether the download is a file saved to disk versus streamed. It adds some context without contradicting annotations.
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 tight sentences carry the core purpose, output formats, local saving, and timestamp syntax. There is no filler, and the most important constraint ('precise authorized time range') 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?
For a tool with six parameters and no output schema, the description plus the schema and annotations cover the essential details: purpose, format choices, timestamp formats, and authorization flag. The main omission is explicit guidance on choosing download_clip over download_media, but this is a minor gap given the strong schema coverage.
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 all six parameters. The description's mention of timestamp formats and MP4/MP3 output is helpful but largely repeats what the schema already states, so the baseline of 3 applies.
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 states a specific verb and resource: 'Download only a precise authorized time range locally as MP4 video or MP3 audio.' The 'only ... time range' wording differentiates it from the sibling download_media, which implies full-media downloads, so an agent can tell them apart without opening the schema.
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 extracting a specific time range rather than downloading entire media, but it never explicitly says when to prefer download_clip over download_media or inspect_media. The context is clear enough to infer the primary use case, but no exclusions or alternatives are named.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Download a complete authorized media item locally as MP4 video or MP3 audio. This writes a file and can use significant bandwidth and storage.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | Public HTTP or HTTPS media page URL | |
| quality | No | 'best', a video height such as 1080p, or an audio bitrate such as 192k | best |
| media_format | No | Output media format | mp4 |
| confirm_authorized | No | True only after the user confirms they may download this media |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses key side effects: it writes a file, consumes significant bandwidth and storage, and requires authorization. This goes beyond the annotations and sets realistic expectations.
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 short sentences with no filler. It front-loads the main action and then notes the important side effects.
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 straightforward download tool with a fully described schema, the description provides enough context about the action, side effects, and authorization requirement. No output schema is needed for this simple operation.
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 full descriptions for all four parameters, including the confirm_authorized flag. The tool description adds no per-parameter detail beyond what the schema covers, so the baseline of 3 applies.
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 downloads a complete media item locally in MP4 or MP3 format, which is specific and distinguishes it from clip-only or inspection tools.
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?
It conveys that the tool is for complete authorized media downloads and hints at the need for user confirmation, but it does not explicitly direct users to download_clip for partial clips or inspect_media for previews.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Inspect a public media URL and return normalized metadata and available formats without downloading it.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | Public HTTP or HTTPS media page URL |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint and openWorldHint. The description adds the important behavioral trait that it does not download the media, which is useful beyond the annotations and clarifies the tool's non-destructive nature. No contradiction exists.
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?
One efficient sentence with no filler; the core action and key non-downloading behavior are 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?
For a simple one-parameter read-only inspection tool, the description covers purpose, output, and the key non-downloading behavior. Minor gaps include no explicit connection to list_supported_sites or failure conditions for unsupported URLs.
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% and the sole url parameter is already well described as a public HTTP/HTTPS media page URL. The tool description mostly restates 'public media URL' and adds no additional syntax, examples, or constraints.
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 ('Inspect'), a clear resource ('public media URL'), and states the outcome ('return normalized metadata and available formats'), which distinguishes it from sibling download tools.
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?
It clearly implies use when metadata/formats are needed without downloading, and 'without downloading it' contrasts with download_media and download_clip. However, it does not explicitly name alternatives or state when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List or search extractor names provided by the locally installed yt-dlp version. An extractor name indicates potential support, not a permanent compatibility guarantee.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum names to return | |
| query | No | Optional case-insensitive extractor-name filter |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds a useful caveat that extractor names indicate potential support, not a permanent compatibility guarantee. The readOnlyHint annotation already signals no side effects, and the description adds relevant behavioral nuance beyond that.
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 brief, direct, and front-loaded with the core action and resource. Every clause earns its place, including the caveat about compatibility, without unnecessary detail.
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 simple listing tool, the description gives enough context: what is returned (extractor names), what the input controls (limit and query), and an important caveat about support durability. No output schema is provided, but the return value is clear from the description.
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 describes both parameters: limit and query. The description does not add much beyond the schema, though it does align 'search' with the query parameter and 'list' with the overall purpose, keeping semantics clear.
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 the action ('list or search') and resource ('extractor names provided by the locally installed yt-dlp version'). This distinguishes it from sibling tools like inspect_media and download_media, which perform different actions.
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 when to use the tool—when you need to know which extractors are available—but does not explicitly contrast it with alternatives or state when not to use it. Usage is inferable from the sibling tool names, but not directly stated.
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.2download_clipdownload_mediainspect_medialist_supported_sitesScored across 4 tools
Each tool has a clearly distinct purpose: inspecting metadata, downloading full media, downloading a time-range clip, and listing supported sites. No overlap or ambiguity between them.
All tool names follow a consistent verb_noun pattern with lowercase and underscores (inspect_media, download_media, download_clip, list_supported_sites). The naming is predictable and uniform.
With only 4 tools, the server is tightly scoped to its core functionality: inspection, full download, clip download, and site support discovery. This is an appropriate count for a focused media downloader, well within the ideal 3-15 range.
The tool surface covers the essential workflows: inspecting media, downloading full items, downloading clips, and checking site support. Minor gaps like subtitle downloading exist, but the core lifecycle is complete and agents can accomplish the primary tasks without dead ends.
Timestamped transcripts, chapters and clip suggestions from YouTube, Twitch, Kick or TikTok links.
yt-dlp Video Link Extractor - Any URL to Links, 1000+ Sites
Any video URL to LLM-ready transcript. ASR built in, no captions needed. TikTok, X, TED and more.
Transform video, audio and images, and generate media from prompts. FFmpeg, captions, models.
