YouTube Search & Download MCP Server

by easyhak

Overview Schema Related Servers Score Discussions

Python

Local

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v1.0.3
Disambiguation5/5
Each 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.
Naming Consistency5/5
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.
Tool Count5/5
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.
Completeness4/5
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.
Average 3.7/5 across 8 of 8 tools scored. Lowest: 3.1/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- Last stable release on January 4, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
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.
Conciseness4/5
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.
Completeness3/5
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.
Parameters4/5
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.
Purpose4/5
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.
Usage Guidelines2/5
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.
Behavior2/5
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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters3/5
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.
Purpose4/5
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.
Usage Guidelines2/5
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.
Behavior2/5
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.
Conciseness4/5
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.
Completeness3/5
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.
Parameters4/5
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.
Purpose4/5
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.
Usage Guidelines2/5
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.
Behavior2/5
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.
Conciseness4/5
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.
Completeness4/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior3/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. 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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters5/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters5/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior3/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. 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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters5/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![youtube-search-mcp MCP server](https://glama.ai/mcp/servers/easyhak/youtube-search-mcp/badges/card.svg)](https://glama.ai/mcp/servers/easyhak/youtube-search-mcp)

Score Badge

Copy to your README.md:

[![youtube-search-mcp MCP server](https://glama.ai/mcp/servers/easyhak/youtube-search-mcp/badges/score.svg)](https://glama.ai/mcp/servers/easyhak/youtube-search-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

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