Skip to main content
Glama
sfiorini

YouTube MCP Server

by sfiorini
OverviewSchemaRelated ServersScoreDiscussions
JavaScript
Remote

YouTube MCP Server

A Model Context Protocol (MCP) server implementation for YouTube, enabling AI language models to interact with YouTube content through a standardized interface. Optimized for 90% Smithery quality score with comprehensive resources, prompts, and flexible configuration.

Features

Video Information

  • Get video details (title, description, duration, etc.) with direct URLs

  • List channel videos with direct URLs

  • Get video statistics (views, likes, comments)

  • Search videos across YouTube with direct URLs

  • NEW: Enhanced video responses include url and videoId fields for easy integration

Transcript Management

  • Retrieve video transcripts

  • Support for multiple languages

  • Get timestamped captions

  • Search within transcripts

Direct Resources & Prompts

  • Resources:

    • youtube://transcript/{videoId}: Access transcripts directly via resource URIs

    • youtube://info: Server information and usage documentation (Smithery discoverable)

  • Prompts:

    • summarize-video: Automated workflow to get and summarize video content

    • analyze-channel: Comprehensive analysis of a channel's content strategy

  • Annotations: All tools include capability hints (read-only, idempotent) for better LLM performance

Channel Management

  • Get channel details

  • List channel playlists

  • Get channel statistics

  • Search within channel content

Playlist Management

  • List playlist items

  • Get playlist details

  • Search within playlists

  • Get playlist video transcripts

Related MCP server: YouTube MCP Server Enhanced

Installation

Quick Setup for Claude Desktop

  1. Install the package:

npm install -g @sfiorini/youtube-mcp

  1. Add to your Claude Desktop configuration (~/Library/Application Support/Claude/claude_desktop_config.json on macOS or %APPDATA%\Claude\claude_desktop_config.json on Windows):

{
  "mcpServers": {
    "youtube-mcp": {
      "command": "youtube-mcp",
      "env": {
        "YOUTUBE_API_KEY": "your_youtube_api_key_here"
      }
    }
  }
}

Alternative: Using NPX (No Installation Required)

Add this to your Claude Desktop configuration:

{
  "mcpServers": {
    "youtube": {
      "command": "npx",
      "args": ["-y", "@sfiorini/youtube-mcp"],
      "env": {
        "YOUTUBE_API_KEY": "your_youtube_api_key_here"
      }
    }
  }
}

Installing via Smithery

To install YouTube MCP Server for Claude Desktop automatically via Smithery:

npx -y @smithery/cli@latest install @sfiorini/youtube-mcp --client claude

Configuration

Set the following environment variables:

  • YOUTUBE_API_KEY: Your YouTube Data API key (required)

  • YOUTUBE_TRANSCRIPT_LANG: Default language for transcripts (optional, defaults to 'en')

Using with VS Code

For one-click installation, click one of the install buttons below:

Install with NPX in VS Code Install with NPX in VS Code Insiders

Manual Installation

If you prefer manual installation, first check the install buttons at the top of this section. Otherwise, follow these steps:

Add the following JSON block to your User Settings (JSON) file in VS Code. You can do this by pressing Ctrl + Shift + P and typing Preferences: Open User Settings (JSON).

{
  "mcp": {
    "inputs": [
      {
        "type": "promptString",
        "id": "apiKey",
        "description": "YouTube API Key",
        "password": true
      }
    ],
    "servers": {
      "youtube": {
        "command": "npx",
        "args": ["-y", "@sfiorini/youtube-mcp"],
        "env": {
          "YOUTUBE_API_KEY": "${input:apiKey}"
        }
      }
    }
  }
}

Optionally, you can add it to a file called .vscode/mcp.json in your workspace:

{
  "inputs": [
    {
      "type": "promptString",
      "id": "apiKey",
      "description": "YouTube API Key",
      "password": true
    }
  ],
  "servers": {
    "youtube": {
      "command": "npx",
      "args": ["-y", "@sfiorini/youtube-mcp"],
      "env": {
        "YOUTUBE_API_KEY": "${input:apiKey}"
      }
    }
  }
}

YouTube API Setup

  1. Go to Google Cloud Console

  2. Create a new project or select an existing one

  3. Enable the YouTube Data API v3

  4. Create API credentials (API key)

  5. Copy the API key for configuration

Examples

Managing Videos

// Get video details (now includes URL)
const video = await youtube.videos.getVideo({
  videoId: "dQw4w9WgXcQ"
});

// Enhanced response now includes:
// - video.url: "https://www.youtube.com/watch?v=dQw4w9WgXcQ"
// - video.videoId: "dQw4w9WgXcQ"
// - All original YouTube API data

// Get video transcript
const transcript = await youtube.transcripts.getTranscript({
  videoId: "video-id",
  language: "en"
});

// Search videos (results now include URLs)
const searchResults = await youtube.videos.searchVideos({
  query: "search term",
  maxResults: 10
});

// Each search result includes:
// - result.url: "https://www.youtube.com/watch?v={videoId}"
// - result.videoId: "{videoId}"
// - All original YouTube search data

Managing Channels

// Get channel details
const channel = await youtube.channels.getChannel({
  channelId: "channel-id"
});

// List channel videos
const videos = await youtube.channels.listVideos({
  channelId: "channel-id",
  maxResults: 50
});

Managing Playlists

// Get playlist items
const playlistItems = await youtube.playlists.getPlaylistItems({
  playlistId: "playlist-id",
  maxResults: 50
});

// Get playlist details
const playlist = await youtube.playlists.getPlaylist({
  playlistId: "playlist-id"
});

Enhanced Response Structure

Video Objects with URLs

All video-related responses now include enhanced fields for easier integration:

interface EnhancedVideoResponse {
  // Original YouTube API fields
  kind?: string;
  etag?: string;
  id?: string | YouTubeSearchResultId;
  snippet?: YouTubeSnippet;
  contentDetails?: any;
  statistics?: any;

  // NEW: Enhanced fields
  url: string;           // Direct YouTube video URL
  videoId: string;       // Extracted video ID
}

Example Enhanced Response

{
  "kind": "youtube#video",
  "id": "dQw4w9WgXcQ",
  "snippet": {
    "title": "Never Gonna Give You Up",
    "channelTitle": "Rick Astley",
    "description": "Official video for \"Never Gonna Give You Up\""
  },
  "statistics": {
    "viewCount": "1.5B",
    "likeCount": "15M"
  },
  // Enhanced fields:
  "url": "https://www.youtube.com/watch?v=dQw4w9WgXcQ",
  "videoId": "dQw4w9WgXcQ"
}

Benefits

  • Easy URL Access: No need to manually construct URLs

  • Consistent Structure: Both search and individual video responses include URLs

  • Backward Compatible: All existing YouTube API data is preserved

  • Type Safe: Full TypeScript support available

Development

# Install dependencies
npm install

# Build TypeScript to JavaScript
npm run build

# Development mode with auto-rebuild and hot reload
npm run dev

# Start the server (requires YOUTUBE_API_KEY)
npm start

# Publish to npm (runs build first)
npm run prepublishOnly

Architecture

This project uses a dual-architecture service-based design with the following features:

  • Shared Utilities: Single source of truth for all MCP server configuration (src/server-utils.ts)

  • Modern McpServer: Updated from deprecated Server class to the new McpServer

  • Dynamic Version Management: Version automatically read from package.json

  • Type-Safe Tool Registration: Uses zod schemas for input validation

  • ES Modules: Full ES module support with proper .js extensions

  • Enhanced Video Responses: All video operations include url and videoId fields

  • Lazy Initialization: YouTube API client initialized only when needed

  • Code Deduplication: Eliminated 90% code duplication through shared utilities (407 → 285 lines)

Project Structure

src/
├── server-utils.ts        # 🆕 Shared MCP server utilities (single source of truth)
├── index.ts              # Smithery deployment entry point
├── server.ts             # CLI deployment entry point
├── services/             # Core business logic
│   ├── video.ts         # Video operations (search, getVideo)
│   ├── transcript.ts    # Transcript retrieval
│   ├── playlist.ts      # Playlist operations
│   └── channel.ts       # Channel operations
├── types.ts             # TypeScript interfaces
└── cli.ts               # CLI wrapper for standalone execution

Key Features

  • Smithery Optimized: Achieved 90%+ Smithery quality score with comprehensive resources, prompts, and configuration

  • Shared Utilities Architecture: Eliminated 90% code duplication with single source of truth

  • Enhanced Video Responses: All video objects include direct YouTube URLs

  • Flexible Configuration: Optional config via Smithery UI or environment variables

  • Type-Safe Development: Full TypeScript support with zod validation

  • Modern MCP Tools: Uses registerTool instead of manual request handlers

  • Comprehensive Resources: Discoverable resources and prompts for better LLM integration

  • Error Handling: Comprehensive error handling with descriptive messages

Contributing

See CONTRIBUTING.md for information about contributing to this repository.

License

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

Available Tools

7 tools
channels_getChannelGet Channel InformationB
Read-onlyIdempotent

Get information about a YouTube channel

ParametersJSON Schema
NameRequiredDescriptionDefault
channelIdYesThe YouTube channel ID

TDQS

B3.1/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare read-only and idempotent behavior. Description adds no further behavioral context, but also no contradiction.

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?

Extremely concise single sentence, but a bit too sparse; could include return value hints without losing conciseness.

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?

With no output schema, the description does not explain what information is returned, leaving the agent without critical usage details.

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 coverage is 100%, so the description adds no meaning beyond what the schema already provides for the single parameter.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action (Get) and resource (YouTube channel), but does not differentiate from sibling tools like channels_listVideos.

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?

No guidance on when to use this tool instead of alternatives, or any prerequisites or context.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

channels_listVideosList Channel VideosB
Read-onlyIdempotent

Get videos from a specific channel

ParametersJSON Schema
NameRequiredDescriptionDefault
channelIdYesThe YouTube channel ID
maxResultsNoMaximum number of results to return

TDQS

B3.4/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint and idempotentHint. Description adds no behavioral traits beyond rephrasing the resource scope.

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?

Single sentence with 6 words, no redundancy. Highly concise and front-loaded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Adequate for a simple list operation with annotations indicating safety. Could mention output type or pagination, but not critical given low complexity.

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 already describes both parameters (channelId, maxResults) with 100% coverage. Description adds no further semantics, meeting baseline.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Verb 'get' and resource 'videos from a specific channel' clearly states purpose. Distinguishes from siblings like channels_getChannel and videos_searchVideos.

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?

No guidance on when to use vs alternatives like videos_searchVideos. No exclusions or prerequisites provided.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

playlists_getPlaylistGet Playlist InformationA
Read-onlyIdempotent

Get information about a YouTube playlist

ParametersJSON Schema
NameRequiredDescriptionDefault
playlistIdYesThe YouTube playlist ID

TDQS

A3.7/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already provide readOnlyHint=true and idempotentHint=true, indicating a safe read operation. The description adds no further behavioral traits (e.g., rate limits, return structure), but does not contradict annotations.

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 a single, concise sentence that contains no redundant information, making it easy to parse and effective.

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?

For a simple tool with one parameter and safety annotations, the description is adequate but lacks details on what information the playlist includes (e.g., title, description, privacy status). Without an output schema, the agent is left guessing the return content.

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 100%, with the parameter 'playlistId' clearly described as 'The YouTube playlist ID'. The tool description adds no additional meaning beyond the schema, meeting the baseline.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description explicitly states 'Get information about a YouTube playlist', using a clear verb and resource. This distinguishes it from sibling playlists_getPlaylistItems which returns playlist items, making the purpose clear.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No explicit guidance on when to use this tool versus alternatives. The purpose is implied, but no direction is given for choosing between playlists_getPlaylist and playlists_getPlaylistItems or other siblings.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

playlists_getPlaylistItemsGet Playlist ItemsB
Read-onlyIdempotent

Get videos in a YouTube playlist

ParametersJSON Schema
NameRequiredDescriptionDefault
playlistIdYesThe YouTube playlist ID
maxResultsNoMaximum number of results to return

TDQS

B3.2/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint and idempotentHint, so the tool's safety is clear. The description adds no additional behavioral context (e.g., pagination, return format, ordering). It is adequate but does not exceed the structured data.

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 a single short sentence, front-loaded with the core action. No wasted words. However, it could afford a bit more detail without losing conciseness.

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?

For a simple read tool with no output schema, the description is minimal but functional. It lacks details about what video information is returned (snippet, contentDetails?) and pagination behavior. Adequate for basic use but not 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?

Schema description coverage is 100%, so the schema already explains both parameters. The description adds no extra meaning beyond what is in the schema. Baseline score of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action ('Get') and resource ('videos in a YouTube playlist'), distinguishing it from siblings like playlists_getPlaylist (playlist metadata) and videos_getVideo (single video). It is concise and unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is provided on when to use this tool versus alternatives such as videos_searchVideos or playlists_getPlaylist. The description does not mention context, prerequisites, or exclusion criteria.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

transcripts_getTranscriptGet Video TranscriptA
Read-onlyIdempotent

Get the transcript of a YouTube video

ParametersJSON Schema
NameRequiredDescriptionDefault
videoIdYesThe YouTube video ID
languageNoLanguage code for the transcript

TDQS

A3.7/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint and idempotentHint, so description does not need to restate safety. However, it omits potential edge cases such as missing transcripts or auto-generated content, which would aid the agent.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Single sentence, no extraneous words, front-loaded purpose. Efficient and clear.

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?

No output schema, but the tool is simple. Missing info on transcript format (e.g., plain text with timestamps) or that language is optional. Adequate for basic use but lacks detail.

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?

Input schema has 100% coverage for both parameters (videoId, language), so description adds no additional meaning. Baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb 'Get' and the resource 'transcript of a YouTube video', distinguishing it from sibling tools like channels_getChannel or videos_searchVideos.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No explicit guidance on when to use this tool versus alternatives, nor any mention of prerequisites like video availability or language support. The description implies usage context but does not provide exclusions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

videos_getVideoGet Video DetailsA
Read-onlyIdempotent

Get detailed information about a YouTube video including URL

ParametersJSON Schema
NameRequiredDescriptionDefault
videoIdYesThe YouTube video ID
partsNoParts of the video to retrieve

TDQS

A3.6/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already indicate readonly and idempotent. Description adds that the response includes URL, which is useful context, but does not disclose other behavioral traits like rate limits or permissions.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Single sentence, front-loaded with action, no unnecessary words. Perfectly concise.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no output schema, the description provides some detail about the response (includes URL). However, it omits other possible response fields like statistics or metadata, which could be inferred from the 'parts' parameter. Still adequate for a simple get tool.

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 descriptions already cover both parameters (videoId and parts) with 100% coverage. The description does not add additional parameter-level meaning beyond that.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Description uses specific verb 'Get' and resource 'detailed information about a YouTube video including URL', clearly distinguishing it from sibling tools like videos_searchVideos which searches for videos.

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?

No guidance on when to use this vs alternatives (e.g., videos_searchVideos). Does not specify that it requires a known videoId, nor when not to use it.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

videos_searchVideosSearch VideosA
Read-onlyIdempotent

Search for videos on YouTube and return results with URLs

ParametersJSON Schema
NameRequiredDescriptionDefault
queryYesSearch query
maxResultsNoMaximum number of results to return

TDQS

A3.5/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint and idempotentHint, which cover the main behavioral traits. The description adds no further behavioral details (e.g., rate limits, default maxResults, error handling). With annotations present, the bar is lower, and the description does not contradict them. Score is neutral.

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 a single, concise sentence that efficiently conveys the tool's purpose. It is front-loaded and lacks unnecessary fluff, but could be slightly more structured (e.g., include output details) without becoming verbose.

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 lack of an output schema, the description should provide more context about the return format. It only mentions 'URLs' but does not clarify if other fields (e.g., video ID, title) are included. For a search tool, this omission reduces completeness.

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?

Input schema has 100% coverage with descriptions for both parameters ('query' and 'maxResults'). The description does not add any additional meaning beyond what the schema already provides, so it meets the baseline.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's action ('Search for videos on YouTube') and what it returns ('results with URLs'). It is specific and distinguishes this from sibling tools like channels_getChannel or playlists_getPlaylistItems, which focus on other resources.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description does not provide explicit guidance on when to use this tool versus alternatives. While the sibling tools are different, there is no mention of when search is preferred over listing or getting specific videos. Usage context is only implied.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Install Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.7/5.0
Disambiguation5/5

Each tool targets a distinct resource (channels, playlists, transcripts, videos) with clear verbs (get, list, search), leaving no ambiguity.

Naming Consistency5/5

All tool names follow a consistent resource_verb pattern in snake_case, making them predictable and easy to parse.

Tool Count5/5

With 7 tools, the set is well-scoped for a YouTube information retrieval server, covering main functionalities without being overwhelming.

Completeness4/5

The tools cover channel, playlist, video, and transcript retrieval, but a tool to list a channel's playlists is missing, which is a minor gap.

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/sfiorini/youtube-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server