FastMCP Youtube Dlp Server - A server for downloading YouTube videos and audio using yt-dlp
This MCP server provides 3 YouTube download tools with basic functionality but significant quality gaps. Tool names follow verb_noun convention (get_, download_), which is positive. However, descriptions are minimal (10-50 chars), input schemas are present but parameters lack depth, and there is no output schema documentation. Error handling is rudimentary (binary success/failure strings with no recovery guidance). The server lacks the rigor expected for production use: no parameter constraints, no detailed output structure, no guidance for LLM decision-making, and no handling of edge cases. This is typical community-grade work suitable for simple automation but not for mission-critical agent tooling.
Download a youtube audio from a given URL
Download a youtube video from a given URL
Get the current folder path where downloads are being saved
Minimal parameter descriptions. Both download tools accept only 'url' with a single-sentence description. No guidance on format, validation, or error recovery. LLMs cannot determine whether a plain text URL, a watch?v=ID, or a full playlist link is valid.
No output schema documentation. Tools return unstructured string responses (e.g., 'Success: Video downloaded from ... to path: ...'). LLMs cannot parse which fields to extract, what the path points to, or how to chain this to downstream tools. Baselines show 100% of A+ tools document return types.
Error handling is binary success/failure with no recovery guidance. Errors return 'Error: Failed to download video from {url}' with no indication whether the failure is retryable, user-fixable (invalid URL), or a service outage. Pattern baseline: error responses must tell the LLM what to do next.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 47 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 8 | - | v1 |
No input validation or constraint documentation. The 'url' parameter accepts any string. No regex pattern, no example of valid formats (http://youtube.com/watch?v=..., youtu.be/..., playlist URLs). Baseline: when parameters have format/pattern constraints, state them in descriptions.
Tool descriptions are too terse (10-50 chars). 'Download a youtube video from a given URL' and 'Download a youtube audio from a given URL' provide minimal context. Baselines: average tool description 194 chars; 10-1024 char range. These descriptions lack WHEN to use (vs the audio variant?), what happens to the file, dependencies (yt-dlp must be installed), or expected return format.
No distinction between download variants. Both tools return nearly identical response formats. An LLM cannot determine from the response alone which one was called or distinguish video from audio output. Output should include 'media_type', 'duration', 'size', or similar distinguishing fields.
Subprocess error handling is silent. If yt-dlp is not installed or the command fails, the tool returns 'Error: Failed to download...' without stderr. The LLM cannot diagnose whether the issue is network, invalid URL, rate limiting, or missing dependency.
get_current_download_path returns a formatted string ('Current download path: /home/user/...') instead of a structured object. LLMs cannot reliably extract the path for downstream use. Should return JSON {"path": "...", "exists": bool, "writable": bool}.