Enables searching for videos and playlists, retrieving detailed metadata including duration and chapters, and downloading video or audio content in multiple formats and qualities.
Click on "Install 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., "@YouTube Search & Download MCP Server Search for 'Python tutorial' and download the first video as an mp4"
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.
This is a production-quality Model Context Protocol (MCP) server that allows you to search, get information about, and download YouTube videos and audio without needing a YouTube API key. It's designed to work seamlessly with MCP clients like Claude Desktop and Cursor.
The server is built with / for robust backend operations and FastMCP for a high-performance server framework.
Related MCP server: MCP YouTube-DLP
No API Key Required: Search and download freely using yt-dlp.
Easy Installation: Simple setup with uv or pip. Works seamlessly with MCP clients.
Video & Audio Downloads: Download content in various formats (mp4, mkv, mp3, wav, etc.) and qualities.
Playlist Support: Search for playlists, get playlist details, and retrieve all videos from any playlist.
Rich Metadata: Get detailed video information, including duration, view count, and chapters.
Client Compatibility: Works great with Claude, Cursor, and other MCP-compliant clients.
Robust & Type-Safe: Built on a SOLID architecture with full type safety using Pydantic.
Python 3.10 or higher
uv (recommended) or pip
FFmpeg (must be installed and available in your system's PATH)
Windows: choco install ffmpeg (with Chocolatey) or download from gyan.dev/ffmpeg
macOS: brew install ffmpeg
Linux: sudo apt install ffmpeg (Ubuntu/Debian) or sudo dnf install ffmpeg (Fedora)
Install the package using uv (recommended) or pip:
# Using uv (recommended)
uv pip install youtube-search-mcp
# Or using pip
pip install youtube-search-mcpAfter installation, you can run the server directly:
youtube-search-mcpConfigure your MCP client to connect to the server.
For Claude Desktop or Cursor:
Add this to your MCP client configuration (usually claude_desktop_config.json):
{
"mcpServers": {
"youtube-search": {
"command": "youtube-search-mcp"
}
}
}Or if using uvx (no installation required):
{
"mcpServers": {
"youtube-search": {
"command": "uvx",
"args": ["youtube-search-mcp"]
}
}
}You can customize the server's behavior by setting environment variables. These can be added to your MCP client configuration (e.g., claude_desktop_config.json) or set via a .env file in the project root.
Variable | Description | Default |
| Directory where videos/audio will be saved |
|
| Default video quality ( |
|
| Number of search results to return by default |
|
| Logging level ( |
|
Interested in contributing? Here’s how to set up your development environment.
Git
Python 3.10+
uv (recommended) or pip
FFmpeg (must be installed and available in your system's PATH for development)
Windows: choco install ffmpeg (with Chocolatey) or download from gyan.dev/ffmpeg
macOS: brew install ffmpeg
Linux: sudo apt install ffmpeg (Ubuntu/Debian) or sudo dnf install ffmpeg (Fedora)
Clone the Repository
git clone https://github.com/easyhak/youtube-search-mcp.git
cd youtube-search-mcpInstall Dependencies
Using uv (recommended):
uv syncUsing pip:
python -m venv .venv
# Activate the virtual environment
# Windows: .venv\Scripts\activate
# macOS/Linux: source .venv/bin/activate
pip install -e ".[dev]"Run the Server
Using uv:
uv run python -m youtube_search_mcp.mainOr with activated virtual environment:
python -m youtube_search_mcp.mainFormat Code: uv run black .
Lint Code: uv run ruff check .
Type Check: uv run mypy .
Run Tests: uv run pytest
Contributions are what make the open-source community such an amazing place to learn, inspire, and create. Any contributions you make are greatly appreciated.
Please refer to the Contributing Guidelines for more details.
Distributed under the MIT License. See LICENSE for more information.
Download audio only from a YouTube video.
Args: video_id: YouTube video ID (11 characters) quality: Audio quality preset - "best", "high" (320kbps), "medium" (192kbps), "low" (128kbps) output_dir: Download directory path (uses config default if not specified) format: Output format - "mp3", "m4a", "opus", "wav" (default: "mp3")
Returns: JSON with download status, file path, file size, and metadata
Example: download_audio("dQw4w9WgXcQ", quality="high", format="mp3")
| Name | Required | Description | Default |
|---|---|---|---|
| video_id | Yes | ||
| quality | No | best | |
| output_dir | No | ||
| format | No | mp3 |
| Name | Required | Description |
|---|---|---|
| result | Yes |
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 mentions the return format ('JSON with download status...') and default behaviors (output_dir uses config default, format defaults to mp3), but doesn't cover important aspects like error handling, rate limits, file overwriting behavior, or whether this requires internet access or specific permissions.
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 efficiently structured with a clear purpose statement followed by well-organized sections (Args, Returns, Example). Every sentence serves a purpose - no redundant information. The example demonstrates typical usage without unnecessary elaboration.
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 tool's moderate complexity (4 parameters, 1 required), no annotations, but with an output schema, the description does well by thoroughly documenting parameters and return format. However, it lacks some behavioral context like error conditions or performance characteristics that would be helpful for a download operation. The existence of an output schema reduces but doesn't eliminate the need for some behavioral disclosure.
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?
With 0% schema description coverage, the description fully compensates by providing comprehensive parameter documentation. Each parameter is clearly explained with semantics, constraints (e.g., '11 characters' for video_id), quality presets with bitrates, format options with defaults, and the config default behavior for output_dir. This adds significant value beyond the bare schema.
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 specific action ('Download audio only') and resource ('from a YouTube video'), distinguishing it from sibling tools like 'download_video' which presumably downloads video content. The opening sentence is direct and unambiguous about the tool's function.
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 usage context by specifying 'audio only' and listing quality/format options, which helps differentiate from 'download_video'. However, it doesn't explicitly state when to use this tool versus alternatives or mention any prerequisites like authentication requirements, which would be needed for a perfect score.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Download a YouTube video with configurable quality.
Args: video_id: YouTube video ID (11 characters) quality: Quality preset - "best", "high" (1080p), "medium" (720p), "low" (480p) output_dir: Download directory path (uses config default if not specified) format: Output format - "mp4", "webm", "mkv" (default: "mp4")
Returns: JSON with download status, file path, file size, and metadata
Example: download_video("dQw4w9WgXcQ", quality="high", format="mp4")
| Name | Required | Description | Default |
|---|---|---|---|
| video_id | Yes | ||
| quality | No | best | |
| output_dir | No | ||
| format | No | mp4 |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that the tool downloads a video with configurable quality and format, and returns JSON with status and metadata, which covers basic behavior. However, it lacks details on potential side effects (e.g., file system changes, network usage), error handling, or rate limits, leaving gaps in behavioral transparency.
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 well-structured and front-loaded with the core purpose, followed by organized sections for Args, Returns, and an Example. Every sentence adds value, with no wasted words, and the example illustrates usage efficiently, making it highly concise and easy to parse.
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 complexity (4 parameters, no annotations, but has output schema), the description is mostly complete: it covers purpose, parameters, returns, and includes an example. However, it lacks behavioral details like side effects or error handling, and while the output schema exists, the description could benefit from more context on what 'download status' entails. It's adequate but has minor gaps.
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?
With 0% schema description coverage, the description fully compensates by detailing all 4 parameters: video_id (YouTube ID, 11 characters), quality (presets with resolutions), output_dir (path with default behavior), and format (options with default). It adds meaning beyond the bare schema, including examples and defaults, making parameter semantics clear and comprehensive.
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's purpose with a specific verb ('Download') and resource ('YouTube video'), and distinguishes it from siblings like download_audio (audio vs. video) and get_video_info (info retrieval vs. download). It specifies configurable quality, making the purpose explicit and differentiated.
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 usage context through parameter details (e.g., quality presets, output directory), but does not explicitly state when to use this tool versus alternatives like download_audio or get_video_info. It provides clear guidance on parameter usage but lacks explicit sibling differentiation in usage scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get detailed information about a specific YouTube playlist.
Args: playlist_id: YouTube playlist ID (e.g., "PLrAXtmErZgOeiKm4sgNOknGvNjby9efdf") output_format: Output format - "json" or "markdown" (default: "json")
Returns: Detailed playlist information including title, creator, video count, and description
Example: get_playlist_info("PLrAXtmErZgOeiKm4sgNOknGvNjby9efdf", output_format="markdown")
| Name | Required | Description | Default |
|---|---|---|---|
| playlist_id | Yes | ||
| output_format | No | json |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses the tool's read-only nature implicitly through 'Get' and specifies output format options, but lacks details on rate limits, authentication needs, error conditions, or pagination behavior. It adds some context but leaves significant behavioral gaps uncovered.
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 well-structured with clear sections (Args, Returns, Example) and every sentence adds value. It's front-loaded with the core purpose, followed by necessary details without redundancy. The example is concise and illustrative.
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 tool's moderate complexity (2 parameters, no annotations, but has output schema), the description covers the essential purpose, parameters, and return scope adequately. The output schema existence means return values don't need explanation here, but more behavioral context (e.g., error handling) would improve completeness.
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 0%, so the description must compensate. It clearly explains both parameters: playlist_id (with an example) and output_format (with options and default). This adds essential meaning beyond the bare schema, though it doesn't detail format-specific output structures or playlist_id validation rules.
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 specific action ('Get detailed information') and resource ('about a specific YouTube playlist'), distinguishing it from siblings like get_playlist_videos (which lists videos) or get_video_info (which focuses on individual videos). The purpose is precise and unambiguous.
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 usage when detailed playlist metadata is needed, but provides no explicit guidance on when to choose this over alternatives like search_playlists (for discovery) or get_playlist_videos (for video listings). It lacks explicit when/when-not statements or named alternatives for similar queries.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get list of videos from a YouTube playlist.
Args: playlist_id: YouTube playlist ID (e.g., "PLrAXtmErZgOeiKm4sgNOknGvNjby9efdf") max_results: Maximum number of videos to return (None for all videos, default: None) output_format: Output format - "json" or "markdown" (default: "json")
Returns: List of videos in the playlist with metadata
Example: get_playlist_videos("PLrAXtmErZgOeiKm4sgNOknGvNjby9efdf", max_results=20)
| Name | Required | Description | Default |
|---|---|---|---|
| playlist_id | Yes | ||
| max_results | No | ||
| output_format | No | json |
| Name | Required | Description |
|---|---|---|
| result | Yes |
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 the return format options ('json' or 'markdown') and that it returns a list with metadata, but lacks details on rate limits, authentication needs, error handling, or whether it's a read-only operation. For a tool with no annotations, this leaves significant gaps in understanding its behavior.
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 well-structured and appropriately sized, with a clear purpose statement followed by parameter details, return info, and an example. Each section adds value without redundancy. Minor improvements could include bolding key terms, but overall it's efficient and easy to scan.
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 tool has an output schema (which handles return values), the description covers the basics: purpose, parameters, and a simple example. However, with no annotations and multiple sibling tools, it lacks context on authentication, error cases, and differentiation from alternatives. It's minimally viable but has clear gaps for effective agent use.
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 0%, so the description must compensate. It effectively explains all three parameters: 'playlist_id' is clarified with an example ID format, 'max_results' specifies 'None for all videos' and a default, and 'output_format' defines the two options and default. This adds meaningful context beyond the bare schema, though it could elaborate on constraints like playlist ID validation.
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's purpose: 'Get list of videos from a YouTube playlist.' It specifies the verb ('Get') and resource ('videos from a YouTube playlist'), making the function unambiguous. However, it doesn't explicitly differentiate from sibling tools like 'get_playlist_info' or 'get_video_info', which could cause confusion about when to use each.
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 provides no guidance on when to use this tool versus alternatives. With siblings like 'get_playlist_info' and 'get_video_info' available, there's no indication of whether this tool retrieves different metadata, handles pagination differently, or serves a distinct use case. The example shows basic usage but doesn't address context or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get detailed information about a specific YouTube video.
Args: video_id: YouTube video ID (11 characters, e.g., "dQw4w9WgXcQ") output_format: Output format - "json" or "markdown" (default: "json")
Returns: Detailed video information including description, tags, and statistics
Example: get_video_info("dQw4w9WgXcQ", output_format="markdown")
| Name | Required | Description | Default |
|---|---|---|---|
| video_id | Yes | ||
| output_format | No | json |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It mentions the tool returns 'detailed video information' but doesn't specify what happens with invalid video IDs, rate limits, authentication requirements, or API constraints. The example shows usage but lacks operational context.
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 well-structured with clear sections (Args, Returns, Example) and front-loaded purpose. The example is helpful but could be more concise. Overall efficient with minimal waste.
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 tool has an output schema (which handles return values), the description provides adequate context for a read-only operation. It covers purpose, parameters, and basic usage, though could benefit from more behavioral details given the lack of annotations.
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 0%, so the description must compensate. It provides clear semantics for both parameters: video_id specifies the format (11 characters with example) and output_format explains the two options with default. This adds significant value beyond the bare schema.
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 verb 'Get' and resource 'detailed information about a specific YouTube video', making the purpose explicit. It distinguishes from siblings like download_audio/video (which fetch content) and get_playlist_info (which focuses on playlists).
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 usage when detailed video metadata is needed, but provides no explicit guidance on when to use this versus alternatives like search_videos or validate_provider. No when-not-to-use or prerequisite information is included.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search YouTube for playlists matching a query.
Args: query: Search query string (e.g., "python tutorial playlist") max_results: Maximum number of results to return (1-50, default: 10) output_format: Output format - "json" or "markdown" (default: "json")
Returns: Formatted search results with playlist metadata
Example: search_playlists("machine learning course", max_results=5, output_format="json")
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | ||
| max_results | No | ||
| output_format | No | json |
| Name | Required | Description |
|---|---|---|
| result | Yes |
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 describes the core functionality (searching YouTube) and output formatting options, but doesn't mention rate limits, authentication requirements, error conditions, or whether this is a read-only operation. The description adds basic context but leaves significant behavioral aspects unspecified.
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 well-structured and efficiently organized with clear sections (description, args, returns, example). Every sentence earns its place by providing essential information without redundancy. The front-loaded purpose statement is followed by necessary details in a logical flow.
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 tool's moderate complexity (search operation with 3 parameters), no annotations, and the presence of an output schema, the description is reasonably complete. It covers purpose, parameters, returns, and provides an example. However, it could be more complete by addressing authentication needs, rate limits, or error handling, especially since no annotations exist to fill these gaps.
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?
With 0% schema description coverage, the description fully compensates by providing detailed parameter information. It explains all three parameters: 'query' (search query string with example), 'max_results' (range and default), and 'output_format' (options and default). This adds substantial meaning beyond what the bare schema provides.
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 specific action ('Search YouTube for playlists') and resource ('playlists'), distinguishing it from sibling tools like 'search_videos' (which searches for videos) and 'get_playlist_info' (which retrieves info for a specific playlist). The verb 'search' combined with the resource 'playlists' provides precise differentiation.
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 provides clear context for when to use this tool (searching YouTube for playlists matching a query), but it doesn't explicitly state when NOT to use it or mention specific alternatives. It implies usage through the example and sibling tool names, but lacks explicit guidance on choosing between 'search_playlists' and 'search_videos' or other playlist-related tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search YouTube for videos matching a query.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | ||
| max_results | No | ||
| output_format | No | json |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It states the basic action but doesn't mention important traits like whether this requires authentication, rate limits, what kind of results are returned (e.g., video metadata, URLs), or any constraints on the search. This leaves significant gaps for an agent to understand how to use it effectively.
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 extremely concise - a single sentence that directly states the tool's purpose with zero wasted words. It's front-loaded and gets straight to the point without unnecessary elaboration.
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 tool's moderate complexity (3 parameters, no annotations) but the presence of an output schema, the description is minimally adequate. The output schema helps compensate for missing return value details, but the description lacks crucial behavioral context and parameter guidance that would make it truly complete for effective use.
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?
With 0% schema description coverage, the description provides no parameter information beyond what's implied by the tool name ('query'). It doesn't explain the 'max_results' parameter for limiting results or 'output_format' for controlling response format. However, since there's an output schema, some parameter context might be inferred from expected returns, keeping it at 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 clearly states the action ('Search YouTube for videos') and the resource ('videos matching a query'), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'search_playlists' or 'get_video_info', which would require specifying it's for video search specifically rather than other YouTube content types.
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 provides no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools like 'search_playlists' for playlist searches or 'get_video_info' for retrieving details about specific videos, leaving the agent to guess based on tool names alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Validate that the YouTube search provider is working correctly.
Returns: JSON with validation status and provider information
Example: validate_provider()
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
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 states the tool validates the provider and returns JSON with status and information, which covers basic output behavior. However, it lacks details on potential side effects (e.g., does it perform network calls, log data, or affect system state?), error handling, or performance characteristics (e.g., latency, rate limits). For a tool with zero annotation coverage, this is insufficient to fully inform the agent.
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 concise and front-loaded, with the first sentence clearly stating the purpose. The 'Returns:' and 'Example:' sections are brief and relevant, adding value without redundancy. However, the example 'validate_provider()' is minimal and could be slightly expanded to illustrate typical output, but overall, the structure is efficient with little waste.
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 tool's low complexity (0 parameters) and the presence of an output schema (which handles return value documentation), the description is reasonably complete. It covers the core purpose and output format. However, it lacks context on when to use it relative to siblings and misses behavioral details like side effects or error handling, which are important for a validation tool even with simple inputs. This results in a moderate score.
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 0 parameters, and the input schema has 100% description coverage (though empty). The description does not need to compensate for any parameter gaps, as there are none. It appropriately omits parameter details, aligning with the schema. The baseline for 0 parameters is 4, as the description correctly focuses on the tool's function without unnecessary parameter explanations.
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's purpose: 'Validate that the YouTube search provider is working correctly.' It specifies the verb 'validate' and the target 'YouTube search provider,' making the intent unambiguous. However, it does not explicitly differentiate this tool from its siblings (e.g., search_videos, get_video_info), which are all related to YouTube operations but serve distinct purposes.
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 provides no guidance on when to use this tool versus alternatives. It mentions no prerequisites, context for usage (e.g., troubleshooting, initialization), or comparisons to sibling tools. The example 'validate_provider()' is purely syntactic and does not offer usage context. This leaves the agent without clear direction on appropriate scenarios for invocation.
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. Dates show when Glama detected each change.
v1.0.3download_audiodownload_videoget_playlist_infoget_playlist_videosget_video_infosearch_playlistssearch_videosvalidate_providerEach tool has a clearly distinct purpose with no overlap: download_audio and download_video handle different media types, get_video_info and get_playlist_info retrieve metadata for different entities, search_videos and search_playlists search different content types, get_playlist_videos lists videos within playlists, and validate_provider is a utility tool. The boundaries are well-defined and unambiguous.
All tools follow a consistent verb_noun naming pattern using snake_case, with clear and descriptive names (e.g., download_audio, get_video_info, search_playlists). There are no deviations in style or convention, making the set predictable and easy to understand.
With 8 tools, the count is well-scoped for a YouTube search and download server. It covers core functionalities like downloading (audio/video), retrieving metadata (video/playlist), searching (videos/playlists), and utility (validation), without being excessive or insufficient for the domain.
The tool set provides strong coverage for search, metadata retrieval, and downloading of videos and playlists, with no major gaps for basic operations. However, it lacks tools for updating or managing downloads (e.g., cancel_download, list_downloads) and advanced features like channel operations, which are minor omissions that agents can work around.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
SubDownload exposes YouTube as an MCP-native data source. Connect via OAuth and your AI agent can summarize videos, fetch full transcripts (even for videos with no captions, via AI ASR), search across channels, and save everything into a private knowledge base. Works with Claude, ChatGPT, Cursor, and 40+ MCP clients. Free credits on signup, no card required.
YouTube transcripts, search, channels, playlists and bulk transcript jobs for AI agents. 14 tools.
Download YouTube, TikTok, Vimeo, SoundCloud and 6 more platforms from any MCP AI chatbot.
YouTube transcripts, search, channel/playlist listings and upload tracking for AI agents. No signup.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/easyhak/youtube-search-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
