Skip to main content
Glama

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.x

Linux (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.x

Windows:

  1. Download Python installer from python.org

  2. Run the installer

  3. Check "Add Python to PATH" during installation

  4. Open Command Prompt and verify:

python --version  # Should show Python 3.11.x

2. Installing uv

macOS/Linux:

# Install uv using the official installer
curl -LsSf https://astral.sh/uv/install.sh | sh

# Verify installation
uv --version

Windows (PowerShell):

# Install uv using the official installer
(Invoke-WebRequest -Uri "https://astral.sh/uv/install.ps1" -UseBasicParsing).Content | pwsh -Command -

# Verify installation
uv --version

Alternative Installation Methods:

Using pip (if you prefer):

# Install uv using pip
pip install uv

# Verify installation
uv --version

3. Setting Up Google Cloud Credentials

  1. 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"
  2. 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"
  3. 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"
  4. 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)
  5. 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.json or token.pickle to git

  • Keep your credentials secure and don't share them

  • If credentials are compromised:

    1. Go to Google Cloud Console

    2. Delete the compromised credentials

    3. Create new credentials

    4. Update your local credentials.json

Installation

  1. Clone the repository:

git clone https://github.com/yourusername/youtube-mcp-server.git
cd youtube-mcp-server
  1. Create 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.ps1
  1. Install 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.pem
  1. Set 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 install

Configuration

  1. Create a .env file 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 region
  1. Verify 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.py

Available Tools

  1. Search Videos

@mcp.tool()
async def get_videos(search: str, max_results: int)
  1. Get Video Info

@mcp.tool()
async def get_video_info(video_id: str)
  1. Get Channel Details

@mcp.tool()
async def get_channel_details(channel_id: str)
  1. Get Video Comments

@mcp.tool()
async def get_video_comments_tool(video_id: str, max_results: int = 100)
  1. Get Trending Videos

@mcp.tool()
async def get_trending_videos_tool(region_code: str = "US", max_results: int = 50)
  1. Get Related Videos

@mcp.tool()
async def get_related_videos_tool(video_id: str, max_results: int = 25)
  1. Summarize Video

@mcp.tool()
async def summarize_video(video_id: str, include_comments: bool = True)
  1. 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

  1. Generate Video Quiz

@mcp.tool()
async def generate_video_quiz(video_id: str) -> str

This 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 file

Adding New Tools

  1. Create a new async function in mcp_videos.py

  2. Decorate it with @mcp.tool()

  3. Implement the tool logic

  4. Add appropriate error handling

  5. Update documentation

šŸ“ API Documentation

Response Formats

  1. 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
}
  1. Channel Format

{
    "title": str,
    "subscriber_count": int,
    "video_count": int,
    "view_count": int,
    "description": str,
    "published_at": str
}
  1. Comment Format

{
    "author": str,
    "text": str,
    "like_count": int,
    "published_at": str
}

šŸ¤ Contributing

  1. Fork the repository

  2. Create a feature branch

  3. Commit your changes

  4. Push to the branch

  5. Create a Pull Request

šŸ“„ License

This project is licensed under the MIT License - see the LICENSE file for details.

šŸ™ Acknowledgments

šŸ“ž Support

For support, please:

  1. Check the documentation

  2. Open an issue

  3. Contact the maintainers

šŸ”„ Updates

Stay updated with the project:

šŸ”’ Security

Handling Sensitive Data

āš ļø IMPORTANT: Never commit sensitive files to the repository:

  • token.pickle

  • client_secrets.json

  • .env files

  • Any other credential files

These files are automatically ignored by .gitignore, but if you accidentally commit them:

  1. Remove them from git tracking:

git rm --cached token.pickle
git rm --cached client_secrets.json
  1. Revoke and regenerate any exposed credentials

  2. Update your local .env file with new credentials

  3. Never share or expose these files publicly

Best Practices

  1. Always use environment variables for sensitive data

  2. Keep credentials in .env file (already in .gitignore)

  3. Regularly rotate API keys and tokens

  4. Use OAuth 2.0 for authentication

  5. Monitor GitHub's secret scanning alerts

šŸ–„ļø Claude Desktop Setup

1. Install Claude Desktop

  1. Download Claude Desktop:

    • Visit Claude Desktop

    • Download the appropriate version for your OS:

      • macOS: .dmg file

      • Windows: .exe installer

      • Linux: .AppImage or .deb package

  2. 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

  1. Open Claude Desktop Settings:

    • Click on the gear icon (āš™ļø) or

    • Use keyboard shortcut:

      • macOS: Cmd + ,

      • Windows/Linux: Ctrl + ,

  2. 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"
          ]
        }
      }
    }
  3. Replace Path:

    • Replace <your base directory> with your actual project path

    • Example for different OS:

      // macOS/Linux
      "/Users/username/Documents/youtube-mcp-server"
      
      // Windows
      "C:\\Users\\username\\Documents\\youtube-mcp-server"
  4. Verify Configuration:

    # Test the MCP server path
    cd "<your base directory>/youtube-mcp-server"
    uv run mcp_videos.py

3. Using Claude with MCP

  1. Start Claude Desktop

  2. Connect to MCP Server:

    • The server should start automatically

    • You'll see a connection status indicator

    • Available tools will be listed in the interface

  3. Test the Connection:

    # Try a simple command
    get_videos("python programming", max_results=5)

Troubleshooting MCP Connection

  1. 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 --version
  2. Connection Issues:

    • Verify the server is running

    • Check the configuration path

    • Ensure all dependencies are installed

    • Check the logs in Claude Desktop

  3. 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 tools
generate_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

ParametersJSON Schema
NameRequiredDescriptionDefault
video_idYes
max_cardsNo
categoriesNo
difficultyNo

TDQS

C2.9/5.0
Behavior2/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 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.

Conciseness4/5

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.

Completeness3/5

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.

Parameters3/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 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.

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: '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.

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 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

ParametersJSON Schema
NameRequiredDescriptionDefault
video_idYes

TDQS

C2.9/5.0
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 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.

Conciseness4/5

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.

Completeness3/5

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.

Parameters3/5

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.

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: '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.

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 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

ParametersJSON Schema
NameRequiredDescriptionDefault
channel_idYes

TDQS

C2.9/5.0
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 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.

Conciseness4/5

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.

Completeness2/5

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.

Parameters3/5

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.

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 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.

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 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_video_comments_toolC

Get comments for a video.

Args: video_id: YouTube video ID max_results: Maximum number of comments to return (default: 100)

ParametersJSON Schema
NameRequiredDescriptionDefault
video_idYes
max_resultsNo

TDQS

C2.9/5.0
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 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.

Conciseness4/5

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.

Completeness2/5

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.

Parameters3/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 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.

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 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.

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. 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

ParametersJSON Schema
NameRequiredDescriptionDefault
video_idYes

TDQS

C2.9/5.0
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 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.

Conciseness4/5

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.

Completeness2/5

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.

Parameters3/5

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.

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 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.

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_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

ParametersJSON Schema
NameRequiredDescriptionDefault
searchYes
max_resultsYes

TDQS

C2.9/5.0
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. 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.

Conciseness4/5

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.

Completeness2/5

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.

Parameters3/5

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.

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 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.

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 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)

ParametersJSON Schema
NameRequiredDescriptionDefault
video_idYes
include_commentsNo

TDQS

B3.2/5.0
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. 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.

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 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.

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 (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.

Parameters4/5

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.

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 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.

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_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

B3.4/5.0
Disambiguation5/5

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.

Naming Consistency4/5

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.

Tool Count5/5

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.

Completeness4/5

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

ActivityInactive
ResponsivenessSyncing

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

Related MCP Servers

Latest Blog Posts

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