YouTube MCP Server
Enables searching for YouTube videos, extracting video transcripts with timestamps, and analyzing YouTube content through the YouTube Data API v3.
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., "@YouTube MCP Serversearch for videos about Python tutorials and get transcripts for the top 3"
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.
YouTube MCP Server
A Model Context Protocol (MCP) server that enables Claude Desktop (and other applications) to interact with YouTube, providing search and transcript functionality.
Features
Search YouTube Videos: Search for videos with customizable result counts
Get Video Transcripts: Extract transcripts from YouTube videos using URLs or video IDs
AI-Ready Integration: Seamlessly integrates with Claude Desktop for YouTube content analysis
Related MCP server: YouTube Insights MCP Server
Tools Available
1. search_youtube_videos
Purpose: Search YouTube for videos based on a query
Parameters:
search_term(string): The search querynum_videos(int): Number of videos to return (default: 5, max: 50)
Returns: List of video information including titles, channels, descriptions, URLs, and metadata
2. get_youtube_transcript
Purpose: Extract transcript from a YouTube video
Parameters:
video_url_or_title(string): YouTube video URL or video ID
Returns: Full transcript with timestamps and metadata
3. analyze_youtube_content_prompt
Purpose: AI prompt template for comprehensive YouTube content analysis
Parameters:
search_term(string): Topic to analyzenum_videos(int): Number of videos to analyze
Setup
1. Install Dependencies
# Create virtual environment
python3 -m venv .venv
# Activate virtual environment
source .venv/bin/activate
# Install dependencies
pip install -r requirements.txt2. Get YouTube API Key
Go to Google Cloud Console
Create a new project or select existing one
Enable YouTube Data API v3
Create credentials (API Key)
Copy the API key
3. Configure Environment
# Copy example environment file
cp .env.example .env
# Edit .env and add your YouTube API key
YOUTUBE_API_KEY=your_actual_api_key_here4. Test the Server
# Activate virtual environment
source .venv/bin/activate
# Run the server
python youtube_server.pyIntegration with Claude Desktop
Add this configuration to your Claude Desktop MCP settings:
{
"mcpServers": {
"youtube": {
"command": "local/path/to/uv",
"args": [
"run",
"--directory",
"/Path/to/your/project",
"youtube_server.py"
],
"env": {
"YOUTUBE_API_KEY": "your_key_here"
}
}
}Usage Examples
Once integrated with Claude Desktop, you can:
"Search for videos about machine learning and get transcripts"
"Find the latest videos on climate change and analyze their content"
"Get the transcript of this YouTube video: https://www.youtube.com/watch?v=..."
"Compare different perspectives on AI ethics from YouTube videos"
Error Handling
Missing API Key: Server will warn and search functionality will be limited
Invalid Video IDs: Clear error messages for transcript requests
API Limits: Respects YouTube API quotas and rate limits
Missing Transcripts: Handles videos without available captions
Dependencies
fastmcp: MCP server frameworkgoogle-api-python-client: YouTube Data API accessyoutube-transcript-api: Transcript extraction
License
This project is open source and available under standard licensing terms.
Available Tools
2 toolsget_youtube_transcriptB
Get the transcript of a YouTube video.
Args:
video_url_or_title: YouTube video URL or video ID
Returns:
Dictionary containing the video transcript and metadata
| Name | Required | Description | Default |
|---|---|---|---|
| video_url_or_title | Yes |
TDQS
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 returns a 'Dictionary containing the video transcript and metadata,' which gives some output context, but lacks details on error handling (e.g., invalid URLs, unavailable transcripts), rate limits, authentication needs, or performance characteristics. This is a significant gap for a tool with no annotation coverage.
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 concise, with three sentences that efficiently cover purpose, input, and output. Each sentence adds value: the first states the tool's function, the second explains the parameter, and the third describes the return value. There's no redundant or unnecessary information.
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 (single parameter, no annotations, no output schema), the description is minimally adequate. It covers the basic purpose and parameter semantics but lacks usage guidelines, detailed behavioral context, and output specifics. Without annotations or an output schema, more completeness would be beneficial, but it meets a baseline level.
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 description coverage is 0%, but the description compensates by explaining the parameter 'video_url_or_title' as 'YouTube video URL or video ID.' This adds meaning beyond the schema's generic 'string' type. However, it doesn't provide examples, format details, or constraints, leaving some ambiguity. With one parameter and partial compensation, a baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Get the transcript of a YouTube video.' It specifies the verb ('Get') and resource ('transcript of a YouTube video'), making it easy to understand what the tool does. However, it doesn't explicitly differentiate from its sibling 'search_youtube_videos' (which likely searches for videos rather than fetching transcripts).
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 the sibling tool 'search_youtube_videos' or clarify scenarios where this tool is appropriate (e.g., after identifying a specific video). There's also no information about prerequisites, such as needing a valid video URL or ID.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_youtube_videosB
Search YouTube videos based on a search term.
Args:
search_term: The search query for YouTube videos
num_videos: Number of videos to retrieve (default: 5, max: 50)
Returns:
List of video information dictionaries containing title, video_id, channel, description, etc.
| Name | Required | Description | Default |
|---|---|---|---|
| search_term | Yes | ||
| num_videos | No |
TDQS
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 tool searches videos and returns a list, but lacks details on permissions, rate limits, pagination, error handling, or whether it's a read-only operation. The default and max values for 'num_videos' are noted, but broader behavioral traits are undocumented.
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 appropriately sized and front-loaded, starting with the core purpose, followed by structured sections for Args and Returns. Each sentence adds value, with no redundant information. It could be slightly more concise by integrating the default/max details into the Args section more seamlessly, but overall it's efficient.
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, no output schema), the description is somewhat complete but has gaps. It covers the purpose and parameters well, but lacks details on behavioral aspects like authentication, rate limits, or error handling. The return format is described generically ('List of video information dictionaries'), but without an output schema, more specifics would be helpful.
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 description adds significant meaning beyond the input schema, which has 0% schema description coverage. It explains that 'search_term' is 'The search query for YouTube videos' and 'num_videos' specifies 'Number of videos to retrieve (default: 5, max: 50)', providing clear semantics and constraints not present in the schema. This compensates well for the low schema coverage.
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: 'Search YouTube videos based on a search term.' It specifies the verb ('search'), resource ('YouTube videos'), and scope ('based on a search term'). However, it doesn't explicitly differentiate from its sibling tool 'get_youtube_transcript', which appears to serve a different function (retrieving transcripts rather than searching videos).
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 the parameter descriptions (e.g., 'search_term' for queries, 'num_videos' for limiting results), but doesn't provide explicit guidance on when to use this tool versus alternatives or any prerequisites. It mentions a sibling tool but doesn't compare or contrast their use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
2 tool updates
v0.1.0- First observed
get_youtube_transcript - First observed
search_youtube_videos
TDQS
Scored across 2 tools
The two tools have completely distinct purposes: one retrieves transcripts for specific videos, while the other searches for videos based on queries. There is no overlap in functionality, making it impossible for an agent to confuse them.
Both tools follow a consistent verb_noun pattern with clear, descriptive names: get_youtube_transcript and search_youtube_videos. The naming convention is uniform and predictable throughout the set.
With only two tools, this server feels severely underpowered for YouTube integration. Key operations like uploading videos, managing playlists, getting video details, or interacting with comments are missing, making the surface too thin for meaningful YouTube automation.
The toolset is highly incomplete for a YouTube server. While transcript fetching and video search are useful, there are major gaps: no CRUD operations for videos/channels/playlists, no interaction capabilities (likes/comments), and no metadata retrieval beyond search results. This will cause significant agent failures in typical YouTube workflows.
Maintenance
Related MCP Connectors
YouTube transcripts, search, channel browsing, and playlists for AI agents via MCP.
Search YouTube, read video metadata, and fetch transcripts with language preferences
YouTube transcripts, search, channels, playlists and bulk transcript jobs for AI agents. 14 tools.
YouTube video search with transcript extraction as first-class output.
Related MCP Servers
- FlicenseNot gradedqualityDmaintenanceEnables interaction with YouTube through the YouTube Data API, allowing users to search for videos, playlists, and channels, generate video titles using AI, and manage YouTube content through natural language commands.22-
- AlicenseBqualityCmaintenanceEnables extraction of transcripts, keyword-based video search with metadata retrieval, and channel information discovery from YouTube videos through natural language interaction.34MIT
- AlicenseAqualityDmaintenanceEnables AI tools to access YouTube content, including transcript extraction, video/channel info, and search.413 npmMIT
- FlicenseNot gradedqualityDmaintenanceEnables LLMs to interact with YouTube videos by fetching transcripts, summarizing content, and answering questions based on video context.-