YouTube MCP Server
Uses Google Cloud Console for authentication and credential management to access YouTube Data API v3 through OAuth 2.0.
Enables interaction with YouTube content through tools for video search, retrieval of video information and transcripts, channel statistics, comment analysis, trending videos discovery, generating educational flashcards and quizzes from video content, and comprehensive video summarization.
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 MCP Serversearch for Python tutorial videos from the last month"
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
Model Contex Protocol (MCP) server that enables AI models to interact with YouTube content through a standardized interface. This server provides a set of tools for video search, content analysis, comment processing, and more.
š Features
š Video Search & Discovery
Search YouTube videos
Get trending videos
Find related content
Channel information
š Content Analysis
Detailed video information
Channel statistics
Video transcripts
Comprehensive summaries
š¬ Social Features
Comment retrieval
Comment analysis
User interaction data
Related MCP server: YouTube MCP Server
š Quick Start
Prerequisites
1. Installing Python
macOS:
# Using Homebrew (recommended)
brew install python@3.11
# Verify installation
python3 --version # Should show Python 3.11.xLinux (Ubuntu/Debian):
# Update package list
sudo apt update
# Install Python
sudo apt install python3.11 python3.11-venv
# Verify installation
python3 --version # Should show Python 3.11.xWindows:
Download Python installer from python.org
Run the installer
Check "Add Python to PATH" during installation
Open Command Prompt and verify:
python --version # Should show Python 3.11.x2. Installing uv
macOS/Linux:
# Install uv using the official installer
curl -LsSf https://astral.sh/uv/install.sh | sh
# Verify installation
uv --versionWindows (PowerShell):
# Install uv using the official installer
(Invoke-WebRequest -Uri "https://astral.sh/uv/install.ps1" -UseBasicParsing).Content | pwsh -Command -
# Verify installation
uv --versionAlternative Installation Methods:
Using pip (if you prefer):
# Install uv using pip
pip install uv
# Verify installation
uv --version3. Setting Up Google Cloud Credentials
Create a Google Cloud Project:
# Go to Google Cloud Console https://console.cloud.google.com # Click on "Select a Project" at the top # Click "New Project" # Name it (e.g., "youtube-mcp-server") # Click "Create"Enable YouTube Data API:
# In the Google Cloud Console: # 1. Go to "APIs & Services" > "Library" # 2. Search for "YouTube Data API v3" # 3. Click "Enable"Create OAuth 2.0 Credentials:
# In the Google Cloud Console: # 1. Go to "APIs & Services" > "Credentials" # 2. Click "Create Credentials" > "OAuth client ID" # 3. Select "Desktop app" as application type # 4. Name it (e.g., "YouTube MCP Client") # 5. Click "Create"Download and Store Credentials:
# 1. After creating credentials, click "Download JSON" # 2. Rename the downloaded file to 'credentials.json' # 3. Move it to your project root: mv ~/Downloads/client_secret_*.json ./credentials.json # Verify the file exists and has correct permissions ls -l credentials.json # Should show -rw------- (readable only by you)First-time Authentication:
# Run the server once to authenticate python mcp_videos.py # This will: # 1. Open your browser # 2. Ask you to sign in to Google # 3. Grant permissions to the application # 4. Create a token.pickle file (automatically ignored by git)
ā ļø Important Security Notes:
Never commit
credentials.jsonortoken.pickleto gitKeep your credentials secure and don't share them
If credentials are compromised:
Go to Google Cloud Console
Delete the compromised credentials
Create new credentials
Update your local
credentials.json
Installation
Clone the repository:
git clone https://github.com/yourusername/youtube-mcp-server.git
cd youtube-mcp-serverCreate and activate a virtual environment:
# Create virtual environment
python -m venv .venv
# Activate virtual environment
# On macOS/Linux:
source .venv/bin/activate
# On Windows (Command Prompt):
.venv\Scripts\activate
# On Windows (PowerShell):
.venv\Scripts\Activate.ps1Install dependencies using uv:
# Install project in editable mode
uv pip install -e .
# If you encounter any SSL errors on macOS, you might need to:
export SSL_CERT_FILE=/etc/ssl/cert.pemSet up YouTube API credentials:
Go to Google Cloud Console
Create a new project
Enable YouTube Data API v3
Create credentials (OAuth 2.0 Client ID)
Download the credentials and save as
client_secrets.json
Development Setup
For development, you might want to install additional tools:
# Install development dependencies
uv pip install -e ".[dev]"
# Install pre-commit hooks
pre-commit installConfiguration
Create a
.envfile in the project root:
# Required environment variables
YOUTUBE_API_KEY=your_api_key_here
# Optional configuration
YOUTUBE_API_QUOTA_LIMIT=10000 # Daily quota limit
YOUTUBE_API_REGION=US # Default regionVerify your setup:
# Check if credentials are properly set up
ls -l credentials.json # Should exist and be readable
ls -l .env # Should exist and be readable
ls -l token.pickle # Should exist after first authentication
# Test the server
python mcp_videos.pyš ļø Usage
Starting the Server
python mcp_videos.pyAvailable Tools
Search Videos
@mcp.tool()
async def get_videos(search: str, max_results: int)Get Video Info
@mcp.tool()
async def get_video_info(video_id: str)Get Channel Details
@mcp.tool()
async def get_channel_details(channel_id: str)Get Video Comments
@mcp.tool()
async def get_video_comments_tool(video_id: str, max_results: int = 100)Get Trending Videos
@mcp.tool()
async def get_trending_videos_tool(region_code: str = "US", max_results: int = 50)Get Related Videos
@mcp.tool()
async def get_related_videos_tool(video_id: str, max_results: int = 25)Summarize Video
@mcp.tool()
async def summarize_video(video_id: str, include_comments: bool = True)Generate Video Flash Cards
@mcp.tool()
async def generate_video_flashcards(
video_id: str,
max_cards: int = 10,
categories: Optional[List[str]] = None,
difficulty: Optional[str] = None
)This tool generates educational flash cards from video content:
Creates different types of cards (Fill in the blank, Q&A, Definition)
Includes timestamps for video reference
Categorizes cards by type and difficulty
Provides card statistics
Example usage:
# Generate 15 flash cards from a video
cards = generate_video_flashcards(
video_id="dQw4w9WgXcQ",
max_cards=15,
categories=["Q&A", "Definition"],
difficulty="Medium"
)
# Generate all types of cards
cards = generate_video_flashcards(
video_id="dQw4w9WgXcQ",
max_cards=20
)Card Types:
Fill in the blank: Tests recall of specific terms or concepts
Q&A: Questions about key points in the video
Definition: Explains important concepts
Difficulty Levels:
Easy: Basic recall and understanding
Medium: Application of concepts
Hard: Complex concepts and relationships
Generate Video Quiz
@mcp.tool()
async def generate_video_quiz(video_id: str) -> strThis tool generates a comprehensive quiz from video content:
Creates multiple choice questions
Generates true/false statements
Includes fill-in-the-blank questions
Uses video metadata, transcript, and description
Provides answers and explanations
Example usage:
# Generate a quiz from a video
quiz = generate_video_quiz("dQw4w9WgXcQ")Quiz Features:
Multiple Choice Questions
Based on video content
Includes video metadata
Tests understanding of key concepts
True/False Questions
Tests factual knowledge
Based on video statistics
Verifies understanding of claims
Fill in the Blank
Tests recall of specific terms
Uses transcript content
Focuses on key concepts
Quiz Format:
=== Video Quiz ===
Title: [Video Title]
Channel: [Channel Name]
URL: [Video URL]
Question 1 (Multiple Choice):
[Question text]
1. [Option 1]
2. [Option 2]
3. [Option 3]
4. [Option 4]
Answer: [Correct answer]
------------------
Question 2 (True/False):
[Statement]
Answer: True/False
------------------
Question 3 (Fill in the blank):
[Question with blank]
Answer: [Correct answer]
------------------The quiz tool:
Generates exactly 10 questions
Mixes different question types
Includes video context
Provides immediate feedback
Uses video metadata for questions
Incorporates transcript content
Tests different levels of understanding
š Architecture
The project follows a modular architecture:
graph TD
A[LLM Client] --> B[MCP Client]
B --> C[MCP Server]
C --> D[YouTube API]
C --> E[Tool Registry]
C --> F[Data Formatter]
subgraph "Tools"
E --> E1[Video Tools]
E --> E2[Channel Tools]
E --> E3[Comment Tools]
E --> E4[Analysis Tools]
endš§ Development
Project Structure
youtube-mcp-server/
āāā mcp_videos.py # Main server implementation
āāā youtube_api.py # YouTube API client
āāā yt_helper.py # Helper functions
āāā requirements.txt # Project dependencies
āāā .env # Environment variables
āāā .gitignore # Git ignore rules
āāā README.md # This fileAdding New Tools
Create a new async function in
mcp_videos.pyDecorate it with
@mcp.tool()Implement the tool logic
Add appropriate error handling
Update documentation
š API Documentation
Response Formats
Video Format
{
"title": str,
"channel_title": str,
"duration": str,
"description": str,
"view_count": int,
"like_count": int,
"comment_count": int,
"url": str,
"published_at": str
}Channel Format
{
"title": str,
"subscriber_count": int,
"video_count": int,
"view_count": int,
"description": str,
"published_at": str
}Comment Format
{
"author": str,
"text": str,
"like_count": int,
"published_at": str
}š¤ Contributing
Fork the repository
Create a feature branch
Commit your changes
Push to the branch
Create a Pull Request
š License
This project is licensed under the MIT License - see the LICENSE file for details.
š Acknowledgments
FastMCP for the MCP framework
YouTube Data API for the API
All contributors and users of this project
š Support
For support, please:
Check the documentation
Open an issue
Contact the maintainers
š Updates
Stay updated with the project:
š Security
Handling Sensitive Data
ā ļø IMPORTANT: Never commit sensitive files to the repository:
token.pickleclient_secrets.json.envfilesAny other credential files
These files are automatically ignored by .gitignore, but if you accidentally commit them:
Remove them from git tracking:
git rm --cached token.pickle
git rm --cached client_secrets.jsonRevoke and regenerate any exposed credentials
Update your local
.envfile with new credentialsNever share or expose these files publicly
Best Practices
Always use environment variables for sensitive data
Keep credentials in
.envfile (already in.gitignore)Regularly rotate API keys and tokens
Use OAuth 2.0 for authentication
Monitor GitHub's secret scanning alerts
š„ļø Claude Desktop Setup
1. Install Claude Desktop
Download Claude Desktop:
Visit Claude Desktop
Download the appropriate version for your OS:
macOS:
.dmgfileWindows:
.exeinstallerLinux:
.AppImageor.debpackage
Install the Application:
# macOS # 1. Open the .dmg file # 2. Drag Claude to Applications folder # 3. Open from Applications # Windows # 1. Run the .exe installer # 2. Follow the installation wizard # 3. Launch from Start Menu # Linux (Ubuntu/Debian) sudo dpkg -i claude-desktop_*.deb # For .deb package # OR chmod +x Claude-*.AppImage # For AppImage ./Claude-*.AppImage
2. Configure MCP Client
Open Claude Desktop Settings:
Click on the gear icon (āļø) or
Use keyboard shortcut:
macOS:
Cmd + ,Windows/Linux:
Ctrl + ,
Add MCP Configuration:
Navigate to "MCP Settings" or "Advanced Settings"
Add the following configuration:
{ "mcpServers": { "youtube_videos": { "command": "uv", "args": [ "--directory", "<your base directory>/youtube-mcp-server", "run", "mcp_videos.py" ] } } }Replace Path:
Replace
<your base directory>with your actual project pathExample for different OS:
// macOS/Linux "/Users/username/Documents/youtube-mcp-server" // Windows "C:\\Users\\username\\Documents\\youtube-mcp-server"
Verify Configuration:
# Test the MCP server path cd "<your base directory>/youtube-mcp-server" uv run mcp_videos.py
3. Using Claude with MCP
Start Claude Desktop
Connect to MCP Server:
The server should start automatically
You'll see a connection status indicator
Available tools will be listed in the interface
Test the Connection:
# Try a simple command get_videos("python programming", max_results=5)
Troubleshooting MCP Connection
Server Won't Start:
# Check if the path is correct pwd # Should show your project directory # Verify Python environment which python # Should point to your virtual environment # Check uv installation uv --versionConnection Issues:
Verify the server is running
Check the configuration path
Ensure all dependencies are installed
Check the logs in Claude Desktop
Common Errors:
# Path not found # Solution: Use absolute path in configuration # Permission denied # Solution: Check file permissions chmod +x mcp_videos.py # Module not found # Solution: Verify virtual environment source .venv/bin/activate # or appropriate activation command
Available Tools
9 toolsgenerate_video_flashcardsC
Generate flash cards from a YouTube video's content.
Args: video_id: YouTube video ID max_cards: Maximum number of cards to generate (default: 10) categories: List of card categories to include (default: all) difficulty: Filter by difficulty level (Easy/Medium/Hard)
Returns: Formatted string containing flash cards
| Name | Required | Description | Default |
|---|---|---|---|
| video_id | Yes | ||
| max_cards | No | ||
| categories | No | ||
| difficulty | No |
TDQS
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 states the tool generates flashcards but doesn't describe how it processes video content (e.g., transcription, AI analysis), whether it requires internet access or specific permissions, potential rate limits, or error conditions. The description mentions a return format ('Formatted string') but lacks details on structure or pagination.
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. It starts with a clear purpose statement, followed by an 'Args:' section listing parameters with defaults, and ends with a 'Returns:' note. Each sentence adds value, though the parameter explanations could be more detailed given the 0% schema coverage.
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 no annotations, 0% schema coverage, and no output schema, the description is moderately complete. It covers the tool's purpose and parameters but lacks behavioral context (e.g., processing method, limitations) and detailed output information. For a tool with four parameters and no structured documentation, it should provide more guidance on usage and results.
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 lists all four parameters with brief explanations, adding meaning beyond the schema's minimal titles. However, it doesn't elaborate on parameter interactions (e.g., how 'categories' and 'difficulty' filter results), valid values for 'categories' or 'difficulty', or the implications of defaults. The description partially compensates but leaves gaps.
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: 'Generate flash cards from a YouTube video's content.' This specifies the verb ('generate'), resource ('flash cards'), and source ('YouTube video's content'). It distinguishes from siblings like 'generate_video_quiz' by focusing on flashcards rather than quizzes, but doesn't explicitly contrast with other video processing tools like 'summarize_video'.
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 when flashcards are preferable to quizzes (from 'generate_video_quiz') or summaries (from 'summarize_video'), nor does it specify prerequisites like video accessibility or content type suitability. Usage context is implied but not articulated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
generate_video_quizC
Generate a quiz based on the video content.
Args: video_id: YouTube video ID
Returns: A formatted quiz with 10 questions of various types
| Name | Required | Description | Default |
|---|---|---|---|
| video_id | 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 generates a quiz with 10 questions of various types, which adds some context beyond the basic purpose. However, it lacks details on permissions, rate limits, error handling, or whether it's a read-only or mutation operation (though 'generate' suggests creation, this isn't clarified). For a tool with zero annotation coverage, this is a significant gap.
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, with the core purpose stated first. The 'Args' and 'Returns' sections add structure, though they could be more integrated. There's no wasted text, but the formatting is slightly verbose for such a simple tool.
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 complexity (simple generation with one parameter), no annotations, no output schema, and low schema coverage, the description is somewhat complete but has gaps. It covers the purpose and return format, but lacks behavioral details and parameter nuances. It's adequate as a minimum viable description but not fully comprehensive.
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 minimal meaning beyond the input schema. It specifies that 'video_id' is a 'YouTube video ID,' which provides context not in the schema (which has 0% description coverage and only lists 'Video Id' as the title). However, with only one parameter, the baseline is 4, but the description doesn't fully compensate for the low schema coverage by explaining format or constraints (e.g., length, validation). Thus, it's scored slightly below 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 tool's purpose: 'Generate a quiz based on the video content.' It specifies the verb ('generate') and resource ('quiz'), and distinguishes it from sibling tools like 'generate_video_flashcards' or 'summarize_video' by focusing on quiz creation. However, it doesn't explicitly differentiate from all siblings (e.g., 'get_video_info' might also process video content), so it's not a perfect 5.
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 when to choose it over 'generate_video_flashcards' or other video-related tools, nor does it specify prerequisites or exclusions. The context is implied (video-based quiz generation), but explicit usage instructions are absent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_channel_detailsC
Get detailed information about a YouTube channel.
Args: channel_id: YouTube channel ID
| Name | Required | Description | Default |
|---|---|---|---|
| channel_id | 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 only states the action ('Get detailed information') without explaining what 'detailed information' includes, whether it requires authentication, rate limits, error conditions, or the response format. 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 appropriately sized and front-loaded, with the core purpose stated first in a clear sentence. The 'Args' section is concise but could be integrated more smoothly. There's no wasted text, though it lacks structural polish for optimal readability.
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 (a read operation with no annotations, 1 parameter, and no output schema), the description is incomplete. It doesn't explain what 'detailed information' entails, how to handle errors, or the return format. For a tool with zero annotation coverage and no output schema, more context is needed to guide the agent effectively.
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 minimal semantics beyond the input schema. It specifies that 'channel_id' is a 'YouTube channel ID,' which clarifies the parameter's purpose but doesn't provide format examples or constraints. With 0% schema description coverage and 1 parameter, the baseline is 4, but the description only partially compensates by naming the parameter type without further detail.
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 detailed information about a YouTube channel.' It specifies the verb ('Get') and resource ('YouTube channel'), making the action explicit. However, it doesn't distinguish this from sibling tools like 'get_video_info' or 'get_videos,' which also retrieve YouTube data but focus on videos rather than channels.
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 such as 'get_video_info' (for video details) or 'get_videos' (for listing videos), leaving the agent to infer usage based on the resource type (channel vs. video). No exclusions or prerequisites are stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_trending_videos_toolB
Get trending videos for a region.
Args: region_code: Two-letter ISO country code (default: "US") max_results: Maximum number of videos to return (default: 50)
| Name | Required | Description | Default |
|---|---|---|---|
| region_code | No | US | |
| max_results | No |
TDQS
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 only states what the tool does without mentioning any behavioral traits such as rate limits, authentication requirements, pagination, or response format. This leaves significant gaps in understanding how the tool operates in practice.
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 front-loaded with the core purpose in the first sentence, followed by parameter details in a structured 'Args' section. It avoids unnecessary words, but the parameter explanations could be slightly more detailed without sacrificing conciseness, keeping it efficient overall.
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 of fetching trending videos (which may involve API limits, regional variations, or data freshness), the description is incomplete. With no annotations, no output schema, and minimal behavioral context, it fails to provide enough information for reliable use. It should address aspects like response structure or error handling.
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 meaningful semantics for both parameters: it explains that 'region_code' is a 'Two-letter ISO country code' and 'max_results' is the 'Maximum number of videos to return'. Since schema description coverage is 0%, this compensates well by providing essential context beyond the bare schema, though it could include examples or constraints for higher clarity.
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 trending videos for a region.' It specifies the verb ('Get') and resource ('trending videos'), making the function unambiguous. However, it doesn't distinguish this tool from sibling tools like 'get_videos' or 'get_related_videos_tool', which prevents a perfect score.
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 'get_videos' or 'get_related_videos_tool', nor does it specify use cases or prerequisites. The only implied context is the need for trending videos, but this is insufficient for effective tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_video_comments_toolC
Get comments for a video.
Args: video_id: YouTube video ID max_results: Maximum number of comments to return (default: 100)
| Name | Required | Description | Default |
|---|---|---|---|
| video_id | Yes | ||
| max_results | No |
TDQS
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 what the tool does but doesn't mention important behavioral aspects like authentication requirements, rate limits, pagination behavior, comment sorting order, whether it retrieves top-level comments only or includes replies, or what happens when max_results exceeds available comments.
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 concise with a clear purpose statement followed by parameter explanations. The two-sentence structure is efficient, though the 'Args:' section formatting could be slightly cleaner. Every sentence serves a purpose.
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 2 parameters, 0% schema description coverage, no annotations, and no output schema, the description is inadequate. It doesn't explain what the return value looks like (comment structure, fields), doesn't mention error conditions, and provides minimal behavioral context despite the lack of structured metadata.
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 basic semantic meaning for both parameters ('YouTube video ID' and 'Maximum number of comments to return'), which adds value beyond the schema's bare titles. However, it doesn't explain format requirements for video_id or constraints on max_results (minimum/maximum values).
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 'Get comments for a video' - a specific verb ('Get') and resource ('comments for a video'). It distinguishes from some siblings like 'get_video_info' (which gets metadata) or 'summarize_video' (which creates summaries), but doesn't explicitly differentiate from all comment-related tools (though none exist in the sibling list).
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. While the sibling list includes other video-related tools, there's no indication of when to choose this comment-fetching tool over others, nor any prerequisites or constraints for usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_video_infoC
Get detailed information about a video.
Args: video_id: YouTube video ID
| Name | Required | Description | Default |
|---|---|---|---|
| video_id | 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 gets 'detailed information' but doesn't specify what that includes (e.g., metadata, statistics, duration), whether it's a read-only operation, potential rate limits, or error handling. This is inadequate 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 appropriately sized and front-loaded, with the main purpose stated first and args listed clearly. It avoids unnecessary fluff, but the args section could be more integrated into the flow rather than a separate block. Overall, it's 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 complexity (a read operation with no annotations, 0% schema coverage, and no output schema), the description is incomplete. It doesn't explain what 'detailed information' entails, potential return values, or how it differs from siblings. For a tool in this context, more detail is needed to be fully 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 minimal parameter semantics: it mentions 'video_id: YouTube video ID,' which clarifies the parameter's purpose beyond the schema's title 'Video Id.' However, with 0% schema description coverage and only one parameter, this provides basic context but doesn't fully compensate for the lack of schema details (e.g., format examples).
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 as 'Get detailed information about a video,' which is a specific verb+resource combination. However, it doesn't distinguish this from sibling tools like 'get_videos' (plural) or 'get_related_videos_tool,' which might have overlapping functionality. The purpose is clear but lacks sibling 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 no guidance on when to use this tool versus alternatives. With siblings like 'get_videos' (which might list videos) and 'get_related_videos_tool' (which might fetch related content), there's no indication of context, prerequisites, or exclusions. Usage is implied only by the tool name and basic description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_videosC
Get videos for a search query.
Args: search: Search query string max_results: Maximum number of results to return
| Name | Required | Description | Default |
|---|---|---|---|
| search | Yes | ||
| max_results | 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. It states the tool retrieves videos for a search query but lacks details on behavioral traits such as authentication needs, rate limits, pagination, or what happens if no results are found. 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 appropriately sized and front-loaded with the main purpose in the first sentence, followed by a structured 'Args' section. It avoids unnecessary details, though the formatting could be slightly more polished for clarity.
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 of video retrieval, lack of annotations, no output schema, and low schema description coverage, the description is incomplete. It doesn't explain return values, error handling, or how results are structured, leaving key contextual gaps for effective tool 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?
The description includes an 'Args' section that lists and briefly describes the two parameters ('search' and 'max_results'), adding meaning beyond the input schema which has 0% description coverage. However, it doesn't provide details like expected formats for 'search' or constraints for 'max_results', only partially compensating for the schema gap.
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 ('Get') and resource ('videos'), and specifies it's for a search query. However, it doesn't differentiate from sibling tools like 'get_trending_videos_tool' or 'get_related_videos_tool' which might also retrieve videos under different conditions.
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 like 'get_trending_videos_tool' or 'get_related_videos_tool'. It mentions a search query but doesn't specify contexts where this is preferred over other video retrieval tools, leaving usage unclear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
summarize_videoB
Get a comprehensive summary of a YouTube video.
Args: video_id: YouTube video ID include_comments: Whether to include top comments in the summary (default: True)
| Name | Required | Description | Default |
|---|---|---|---|
| video_id | Yes | ||
| include_comments | 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. While 'Get a comprehensive summary' implies a read-only operation, it doesn't specify what 'comprehensive' includes (e.g., transcript analysis, key points, duration), whether there are rate limits, authentication requirements, or what the output format looks like. This leaves significant gaps for an agent to understand the tool's 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 efficiently structured with a clear purpose statement followed by parameter explanations. Every sentence serves a purpose: the first states what the tool does, and the Args section provides necessary parameter details without redundancy. It's appropriately sized for a tool with two parameters.
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 (summarizing video content), lack of annotations, and no output schema, the description is minimally adequate. It covers the basic purpose and parameters but lacks details about the summary format, potential limitations (e.g., video length constraints), or how it differs from sibling tools. This leaves the agent with incomplete context for optimal usage.
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 compensates well by explaining both parameters in the Args section: 'video_id' is clearly identified as a YouTube video ID, and 'include_comments' is explained with its default value and purpose. This adds meaningful context beyond the bare schema, though it doesn't specify format details for the video_id.
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 ('Get') and resource ('comprehensive summary of a YouTube video'), making it immediately understandable. However, it doesn't explicitly differentiate from sibling tools like 'get_video_info' or 'generate_video_flashcards', which might also provide video-related information in different formats.
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_video_info' (likely providing raw metadata), 'generate_video_flashcards' (creating study aids), and 'get_video_comments_tool' (fetching comments), there's no indication of when a summary is preferred over these other options.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
TDQS
Every tool has a clearly distinct purpose with no ambiguity. The tools cover different aspects of YouTube interaction: content generation (flashcards, quiz, summary), information retrieval (video info, channel details, search), and social features (comments, related videos, trending). Each tool name precisely indicates its unique function.
The naming is mostly consistent with a verb_noun pattern (e.g., generate_video_flashcards, get_video_info, summarize_video), but there are minor deviations. Three tools append '_tool' (get_related_videos_tool, get_trending_videos_tool, get_video_comments_tool), which breaks the pattern slightly, though the core naming remains readable and predictable.
With 9 tools, this is well-scoped for a YouTube-focused server. Each tool earns its place by covering distinct functionalities like content analysis, metadata retrieval, and social interactions. The count is neither too sparse nor bloated, fitting typical expectations for a domain-specific server.
The tool surface is largely complete for YouTube content interaction, covering key areas such as video summarization, quiz generation, metadata access, and social features. Minor gaps exist, like the inability to post comments or manage playlists, but these are not critical for core agent workflows and can be worked around.
Maintenance
Resources
Unclaimed servers have limited discoverability.
Looking for Admin?
If you are the server author, to access and configure the admin panel.
Related MCP Connectors
YouTube transcripts, search, channels, playlists and bulk transcript jobs for AI agents. 14 tools.
YouTube transcripts, search, channel/playlist listings and upload tracking for AI agents. No signup.
YouTube public video, comment, reply, channel, search, and speech-to-text transcript tools.
AI-powered YouTube to flashcards with spaced repetition and Anki export
Related MCP Servers
- AlicenseNot gradedqualityDmaintenanceEnables AI language models to interact with YouTube content through a standardized interface, providing tools for retrieving video information, transcripts, channel analytics, and trend analysis.51965MIT
- AlicenseAqualityCmaintenanceEnables AI models to interact with YouTube content including video details, transcripts, channel information, playlists, and search functionality through the YouTube Data API.72210MIT
- AlicenseNot gradedqualityCmaintenanceEnables AI assistants to search videos, read channels, browse playlists, fetch comments, and get transcripts from YouTube using the YouTube Data API v3 and InnerTube API for captions.2GPL 3.0
- FlicenseNot gradedqualityCmaintenanceEnables AI assistants to search videos, channels, and playlists, retrieve video metadata, transcripts, and comments via the YouTube Data API v3.73
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
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/temiedani/youtube-mcp-server'
If you have feedback or need assistance with the MCP directory API, please join our Discord server