YT-NINJA
Supports audio-only playback using ffplay and media processing capabilities for YouTube video content.
Powers AI-driven video analysis features including automated summarization, chapter generation, keyword extraction, topic detection, and highlight generation for YouTube content.
Enables playback of YouTube videos through VLC media player as an alternative to browser-based playback.
Provides comprehensive YouTube video analysis, playback control, data retrieval (video info, playlists, channels, search), transcript management with translation, and AI-powered content processing including summaries, chapters, keywords, topics, and highlights.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type
@followed by the MCP server name and your instructions, e.g., "@YT-NINJAsummarize the key points from this video about AI advancements"
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.
YT-NINJA š„·
A comprehensive YouTube MCP (Model Context Protocol) server that provides AI-powered video analysis, playback control, transcript management, and advanced content processing capabilities.
Features
š¬ Video Playback
Play videos in browser or VLC player
Audio-only playback with ffplay
Video segment playback with timestamp control
Active playback session management
š Data Retrieval
Get detailed video information (title, views, likes, duration, etc.)
Fetch playlist details with all videos
Retrieve channel information and statistics
Search YouTube videos and music
Download video thumbnails in multiple qualities
š Transcript Management
Get official video transcripts
AI-powered transcript generation (when official unavailable)
Translate transcripts to any language
Format transcripts with or without timestamps
š¤ AI-Powered Analysis
Generate video summaries with key points
Auto-generate chapter markers
Extract relevant keywords with relevance scores
Detect topics and categories
Create AI-powered video highlights
Related MCP server: mcp-server-youtube
Installation
Prerequisites
Node.js >= 18.0.0
npm >= 9.0.0
Google Gemini API key (required for AI features)
Optional: VLC Media Player (for VLC playback)
Optional: FFmpeg (for audio playback and processing)
Setup
Clone the repository:
git clone <repository-url>
cd yt-ninjaInstall dependencies:
npm installConfigure environment variables:
cp .env.example .envEdit .env and add your configuration:
# Required
GEMINI_API_KEY=your-google-gemini-api-key
# Optional
DOWNLOAD_DIR=./downloads
TEMP_DIR=./temp
MAX_CONCURRENT_DOWNLOADS=3
LOG_LEVEL=infoBuild the project:
npm run buildConfiguration
Environment Variables
Variable | Required | Default | Description |
| Yes | - | Google Generative AI API key for AI features |
| No |
| Directory for downloaded files |
| No |
| Temporary files directory |
| No |
| Maximum concurrent downloads |
| No |
| Logging level (error, warn, info, debug) |
Getting a Gemini API Key
Visit Google AI Studio
Sign in with your Google account
Click "Create API Key"
Copy the key and add it to your
.envfile
MCP Configuration
Add to your MCP settings file (mcp.json):
{
"mcpServers": {
"yt-ninja": {
"command": "node",
"args": ["/path/to/yt-ninja/dist/index.js"],
"env": {
"GEMINI_API_KEY": "your-api-key-here"
},
"disabled": false
}
}
}Available Tools
Playback Tools
play_youtube_video
Play a YouTube video in browser or VLC player.
Parameters:
url(string, required): YouTube video URLplayer(string, optional): Player type -browserorvlc(default:browser)
Example:
{
"url": "https://www.youtube.com/watch?v=dQw4w9WgXcQ",
"player": "browser"
}Data Retrieval Tools
get_video_info
Get comprehensive information about a YouTube video.
Parameters:
url(string, required): YouTube video URL
Returns: Video title, description, channel, views, likes, duration, tags, thumbnail, etc.
get_playlist_info
Get information about a YouTube playlist.
Parameters:
url(string, required): YouTube playlist URL
Returns: Playlist title, description, video count, total duration, list of videos
get_channel_info
Get information about a YouTube channel.
Parameters:
channelId(string, required): Channel ID or URL
Returns: Channel name, description, subscriber count, total views, video count
search_youtube
Search for videos on YouTube.
Parameters:
query(string, required): Search querymaxResults(number, optional): Maximum results (1-50, default: 10)
Returns: Array of search results with video details
search_music
Search specifically for music on YouTube.
Parameters:
query(string, required): Music search querymaxResults(number, optional): Maximum results (1-50, default: 10)
Returns: Array of music search results
download_thumbnail
Download a video thumbnail image.
Parameters:
url(string, required): YouTube video URLoutputPath(string, optional): Output file pathquality(string, optional): Quality -maxres,high,medium,default(default:maxres)
Transcript Tools
get_transcript
Get the transcript/subtitles of a video.
Parameters:
url(string, required): YouTube video URLlanguage(string, optional): Language code (e.g., 'en', 'es', 'fr')
Returns: Transcript text, language, timestamps, source type
translate_transcript
Translate a video transcript to another language.
Parameters:
url(string, required): YouTube video URLtargetLanguage(string, required): Target language code
Returns: Translated transcript with original timestamps
AI Analysis Tools
summarize_video
Generate an AI-powered summary of a video.
Parameters:
url(string, required): YouTube video URLmaxWords(number, optional): Maximum words in summary (default: 200)
Returns: Summary text, key points, word count
generate_chapters
Auto-generate chapter markers for a video.
Parameters:
url(string, required): YouTube video URL
Returns: Array of chapters with timestamps, titles, and descriptions
get_keywords
Extract relevant keywords from a video.
Parameters:
url(string, required): YouTube video URLcount(number, optional): Number of keywords (default: 15)
Returns: Array of keywords with relevance scores and frequency
detect_topics
Detect topics and categories in a video.
Parameters:
url(string, required): YouTube video URL
Returns: Array of topics with confidence scores and categories
generate_video_highlights
Generate AI-powered video highlights.
Parameters:
url(string, required): YouTube video URLcount(number, optional): Number of highlights (5-10, default: 7)
Returns: Array of highlight moments with timestamps, descriptions, reasons, and scores
Usage Examples
Using with\
AI
Once configured as an MCP server, you can use YT-NINJA through natural language:
"Get information about this video: https://www.youtube.com/watch?v=dQw4w9WgXcQ"
"Summarize this YouTube video in 150 words"
"Generate chapters for this tutorial video"
"Extract the top 20 keywords from this video"
"Get the transcript and translate it to Spanish"Programmatic Usage
import { dataManager, aiAnalyzer, transcriptManager } from 'yt-ninja';
// Get video info
const videoInfo = await dataManager.getVideoInfo('https://youtube.com/watch?v=...');
// Generate summary
const summary = await aiAnalyzer.summarizeVideo('https://youtube.com/watch?v=...', 200);
// Get transcript
const transcript = await transcriptManager.getTranscript('https://youtube.com/watch?v=...');Development
Scripts
npm run dev- Run in development mode with hot reloadnpm run build- Build for productionnpm start- Start the production servernpm run lint- Lint codenpm run format- Format code with Prettiernpm run type-check- Check TypeScript types
Project Structure
yt-ninja/
āāā src/
ā āāā index.ts # Entry point
ā āāā server.ts # MCP server setup
ā āāā integrations/ # External service integrations
ā ā āāā youtube.ts # YouTube API client
ā ā āāā genai.ts # Google GenAI client
ā ā āāā ffmpeg.ts # FFmpeg integration
ā ā āāā process.ts # Process management
ā āāā managers/ # Feature managers
ā ā āāā DataManager.ts # Data retrieval
ā ā āāā PlaybackManager.ts # Playback control
ā ā āāā TranscriptManager.ts # Transcript operations
ā ā āāā AIAnalyzer.ts # AI analysis
ā ā āāā MediaProcessor.ts # Media processing
ā ā āāā AdvancedFeaturesManager.ts # Advanced features
ā āāā types/ # TypeScript type definitions
ā āāā utils/ # Utility functions
āāā dist/ # Compiled output
āāā downloads/ # Downloaded files
āāā .env # Environment configuration
āāā package.jsonError Handling
YT-NINJA provides detailed error messages with suggestions:
{
"success": false,
"error": {
"code": "INVALID_URL",
"message": "Invalid YouTube video URL",
"details": { "url": "..." },
"suggestions": [
"Provide a valid YouTube video URL",
"Example: https://www.youtube.com/watch?v=VIDEO_ID"
]
}
}Available Tools
14 toolsdetect_topicsC
Detect topics in video
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | YouTube video URL |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral disclosure. It reveals nothing about whether this is a read/write operation, what permissions or rate limits apply, what format the output takes, or any side effects. 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 extremely concise at three words, with zero wasted text. It's front-loaded with the core action, though this brevity comes at the cost of completeness. Every word earns its place in conveying the minimal essence.
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 and no output schema, the description is incomplete for a tool that presumably returns detected topics. It doesn't explain what 'topics' are, how they're detected, or what the output format looks like. For a tool with rich sibling context, this leaves significant gaps.
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 100%, with the single parameter 'url' clearly documented as a YouTube video URL. The description adds no additional parameter information beyond what the schema provides, so it meets the baseline for high schema coverage without compensating value.
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 'Detect topics in video' states the basic action (detect) and target (topics in video), but lacks specificity about what 'topics' means or how detection works. It doesn't distinguish from siblings like 'get_keywords' or 'summarize_video', leaving ambiguity about what differentiates this tool.
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?
No guidance is provided on when to use this tool versus alternatives like 'get_keywords' or 'summarize_video'. The description doesn't mention prerequisites, context, or exclusions, leaving the agent to infer usage from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
download_thumbnailC
Download video thumbnail image
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | YouTube video URL | |
| outputPath | No | Output file path (optional) | |
| quality | No | Thumbnail quality (default: maxres) |
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. While 'Download' implies file creation, it doesn't specify where files are saved by default, what happens if outputPath isn't provided, whether authentication is needed, or any rate limits. This leaves significant behavioral gaps for a tool that creates files.
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 perfectly concise at just three words, front-loading the essential information with zero wasted words. Every element earns its place in this minimal but complete statement of 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 3 parameters, no annotations, and no output schema, the description is insufficiently complete. It doesn't explain what happens when the tool executes (file creation behavior), what format the thumbnail is in, or what happens on errors. The minimal description leaves too many operational questions unanswered.
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 100% schema description coverage, the schema already documents all parameters thoroughly. The description adds no additional parameter semantics beyond what's in the schema, so it meets the baseline but doesn't provide extra value.
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 action ('Download') and resource ('video thumbnail image'), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'get_video_info' which might also provide thumbnail data, so it doesn't reach the highest score for 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. There's no mention of prerequisites, when-not-to-use scenarios, or comparison with sibling tools like 'get_video_info' that might provide thumbnail URLs without downloading files.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
generate_chaptersC
Generate chapter markers for video
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | YouTube video URL |
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 what the tool does but doesn't explain how it worksāsuch as whether it analyzes video content, transcripts, or metadata; what format the chapter markers are in; or if there are limitations like video length or processing time. This leaves significant gaps in understanding 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 a single, clear sentence with no wasted words, making it highly concise and front-loaded. It directly communicates the core function without unnecessary elaboration, earning a perfect score for efficiency.
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 (involving video analysis and chapter generation) and lack of annotations or output schema, the description is insufficient. It doesn't explain what the output looks like (e.g., timestamps, titles), any prerequisites, or error handling, leaving the agent with incomplete context for effective 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 input schema has 100% description coverage, with the 'url' parameter documented as 'YouTube video URL'. The description doesn't add any meaning beyond this, such as clarifying URL formats or restrictions. With high schema coverage, the baseline score of 3 is appropriate as the schema handles the parameter documentation adequately.
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 'Generate chapter markers for video' clearly states the action (generate) and resource (chapter markers for video), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'generate_video_highlights' or 'summarize_video' which might have overlapping video analysis functions, preventing 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. With siblings like 'generate_video_highlights' and 'summarize_video' that might serve similar video content analysis purposes, there's no indication of when chapter generation is preferred over other methods, leaving usage ambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
generate_video_highlightsC
Generate AI-powered video highlights
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | YouTube video URL | |
| count | No | Number of highlights (5-10, default: 7) |
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 highlights but lacks details on permissions, rate limits, output format, or processing time. This is a significant gap for a tool that likely involves AI processing and external API calls, making it inadequate for safe and effective use.
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 a single, efficient sentence with zero wasted words. It front-loads the core purpose ('Generate AI-powered video highlights') without unnecessary elaboration, making it easy to parse and understand quickly.
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 AI-powered video processing and the lack of annotations and output schema, the description is insufficient. It doesn't cover behavioral aspects like error handling, output format, or limitations, leaving critical gaps for the agent to operate this tool effectively in a real-world context.
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 100%, so the input schema fully documents the parameters (URL and count). The description adds no additional semantic context beyond what's in the schema, such as explaining what constitutes a 'highlight' or how the count affects output. Baseline 3 is appropriate as the schema handles parameter documentation.
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 'Generate AI-powered video highlights', which specifies the action (generate), method (AI-powered), and resource (video highlights). It distinguishes from siblings like 'summarize_video' or 'generate_chapters' by focusing on highlights rather than full summaries or chapter breakdowns, though it doesn't explicitly contrast them.
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 prerequisites like needing a YouTube URL, nor does it differentiate from similar tools such as 'summarize_video' or 'generate_chapters', leaving the agent to infer usage based on the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_channel_infoC
Get YouTube channel information
| Name | Required | Description | Default |
|---|---|---|---|
| channelId | Yes | Channel ID or URL |
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 but only states the basic action without details on permissions, rate limits, response format, or error handling. It doesn't add meaningful context beyond the obvious read operation implied by 'Get', leaving significant gaps for a tool that likely interacts with an external API.
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 a single, efficient sentence that directly states the tool's purpose without any wasted words. It is appropriately sized and front-loaded, making it easy to parse quickly.
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 lack of annotations and output schema, the description is incomplete for a tool that likely returns structured data from YouTube. It fails to explain what information is retrieved (e.g., statistics, metadata) or behavioral aspects like API limitations, leaving the agent with insufficient context for effective 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?
Schema description coverage is 100%, with the single parameter 'channelId' documented as 'Channel ID or URL' in the schema. The description adds no additional parameter semantics, such as examples or constraints, but the schema provides adequate baseline information, justifying a score of 3.
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 action ('Get') and resource ('YouTube channel information'), making the tool's purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'get_video_info' or 'get_playlist_info' beyond specifying the resource type, 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 like 'get_video_info' or 'get_playlist_info' for related YouTube data. It lacks any context about prerequisites, such as needing a valid channel ID, or exclusions, leaving the agent to infer usage from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_keywordsC
Extract keywords from video
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | YouTube video URL | |
| count | No | Number of keywords (default: 15) |
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 action ('extract') but doesn't explain how the extraction works, what format the keywords are returned in, whether there are rate limits, or any error conditions. This leaves significant gaps in understanding 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 extremely concise at just three words ('Extract keywords from video'), which is front-loaded and wastes no space. Every word contributes directly to stating the tool's purpose without unnecessary elaboration.
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 lack of annotations and output schema, the description is incomplete for a tool with 2 parameters. It doesn't explain the return format (e.g., list of strings, JSON object), error handling, or any behavioral nuances. For a keyword extraction tool, this leaves too much unspecified about how results are structured and delivered.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, with clear documentation for both parameters ('url' as YouTube video URL and 'count' as number of keywords with default). The description doesn't add any meaningful semantic context beyond what's already in the schema, such as explaining what 'keywords' means in this context or how the count affects results.
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 'Extract keywords from video' clearly states the verb ('extract') and resource ('keywords from video'), making the tool's purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'detect_topics' or 'summarize_video' that might also analyze video content, so it doesn't reach the highest 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. With siblings like 'detect_topics' and 'summarize_video' that might overlap in video analysis, there's no indication of when keyword extraction is preferred or what distinguishes it from other content analysis tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_playlist_infoC
Get YouTube playlist information
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | YouTube playlist URL |
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 but offers minimal information. 'Get YouTube playlist information' implies a read-only operation but doesn't specify what information is returned (metadata, video list, statistics), whether there are rate limits, authentication requirements, or any constraints on the URL format beyond what the schema indicates.
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 maximally concise - a single four-word phrase that communicates the core purpose without any wasted words. It's appropriately sized for a simple retrieval tool and front-loads the essential information immediately.
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 no annotations and no output schema, the description is insufficiently complete. It doesn't indicate what 'playlist information' includes (metadata, video list, statistics), whether there are constraints on URL formats beyond 'YouTube playlist URL', or what the return format looks like. Given the lack of structured documentation elsewhere, the description should provide more context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 100% description coverage with the 'url' parameter clearly documented as 'YouTube playlist URL'. The description doesn't add any parameter semantics beyond what the schema provides, but with complete schema coverage, the baseline score of 3 is appropriate as the schema does the heavy lifting for parameter documentation.
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 'Get YouTube playlist information' clearly states the verb ('Get') and resource ('YouTube playlist information'), making the tool's purpose immediately understandable. However, it doesn't differentiate this tool from its sibling 'get_video_info' or 'get_channel_info' - all are 'get X information' tools, so the distinction isn't explicit.
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', 'get_channel_info', and 'search_youtube', there's no indication whether this tool is for playlist metadata, content listing, or other specific playlist-related information versus what other tools provide.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_transcriptC
Get video transcript
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | YouTube video URL | |
| language | No | Language code (optional) |
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. 'Get video transcript' implies a read-only operation, but it doesn't specify whether authentication is required, rate limits apply, what happens with invalid URLs, or the format of the returned transcript. For a tool with zero annotation coverage, this leaves critical behavioral traits undocumented.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at three words, front-loading the core purpose with zero wasted text. Every word ('Get', 'video', 'transcript') earns its place by conveying essential information without redundancy or fluff, making it efficient for quick understanding.
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 (fetching transcripts from YouTube), lack of annotations, and no output schema, the description is incomplete. It doesn't explain what the transcript output looks like (e.g., text format, timestamps), error conditions, or dependencies on external services. For a tool with these gaps, the description should provide more context 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 input schema has 100% description coverage, with clear documentation for both parameters ('url' as YouTube video URL and 'language' as optional language code). The description adds no additional meaning beyond the schema, such as example URLs or supported language codes. With high schema coverage, the baseline score of 3 is appropriate, as the schema does the heavy lifting.
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 'Get video transcript' clearly states the verb ('Get') and resource ('video transcript'), making the basic purpose understandable. However, it doesn't specify what type of video (YouTube is only implied by the parameter schema) or distinguish it from sibling tools like 'translate_transcript' or 'summarize_video', leaving the scope somewhat vague.
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 prefer this over 'get_video_info' (which might include transcript data) or 'translate_transcript', nor does it specify prerequisites like needing a valid YouTube URL. Without any context, the agent must infer usage from the tool name alone.
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 YouTube video information
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | YouTube video URL |
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 retrieves information, implying a read-only operation, but doesn't specify what information is returned (e.g., metadata, statistics), whether there are rate limits, authentication needs, or error handling. This leaves significant gaps 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 a single, efficient sentence that directly states the tool's purpose without unnecessary words. It is front-loaded and appropriately sized for a simple tool, with zero waste or redundancy.
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 lack of annotations and output schema, the description is incomplete. It doesn't explain what 'video information' includes (e.g., title, duration, views), return format, or potential errors. For a tool with no structured behavioral or output data, the description should provide more context 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 input schema has 100% description coverage, with the 'url' parameter clearly documented as a 'YouTube video URL'. The description doesn't add any additional meaning beyond this, such as URL format examples or validation rules. With high schema coverage, the baseline score of 3 is appropriate as the schema handles the parameter documentation adequately.
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 action ('Get') and resource ('YouTube video information'), making the purpose understandable. However, it doesn't distinguish this tool from potential sibling tools like 'get_channel_info' or 'get_playlist_info' beyond specifying 'video' information, which is somewhat implied but not explicitly contrasted.
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_channel_info' for channel data or 'get_playlist_info' for playlist details, nor does it specify prerequisites such as needing a valid YouTube URL. 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.
play_youtube_videoB
Play YouTube video in browser or VLC
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | YouTube video URL | |
| player | No | Player to use (default: browser) |
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 plays videos but doesn't describe how (e.g., opens a new window, streams in background), error handling (e.g., invalid URLs), side effects (e.g., browser pop-ups), or performance (e.g., loading times). For a tool with potential user interaction and no 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 a single, efficient sentence with zero waste. It front-loads the core action ('Play YouTube video') and specifies the key detail ('in browser or VLC') without redundancy. Every word earns its place, making it highly concise and well-structured.
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 (playback with platform choice), no annotations, and no output schema, the description is minimally adequate. It covers the basic purpose but lacks details on behavior, error cases, or integration context. With 100% schema coverage for inputs, it meets a baseline but doesn't fully compensate for missing behavioral transparency.
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 100%, with clear documentation for both parameters ('url' as YouTube video URL, 'player' with enum and default). The description adds no additional parameter semantics beyond what the schema provides, such as URL format examples or player-specific behaviors. Baseline 3 is appropriate when the schema does the heavy lifting.
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 action ('Play') and resource ('YouTube video'), specifying the target platforms ('in browser or VLC'). It distinguishes from siblings like 'get_video_info' or 'download_thumbnail' by focusing on playback rather than metadata extraction or content processing. However, it doesn't explicitly differentiate from all siblings (e.g., 'search_youtube' is for discovery, not playback).
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 prerequisites (e.g., needing a valid YouTube URL), exclusions (e.g., not for audio-only playback), or comparisons to siblings like 'get_video_info' for metadata. Usage is implied by the action but lacks explicit context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_musicC
Search YouTube for music
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Music search query | |
| maxResults | No | Maximum results (1-50, default: 10) |
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 'Search' implies a read-only operation, the description doesn't address important behavioral aspects like authentication requirements, rate limits, result format, pagination, or whether this is a real-time search versus cached results. For a search tool with zero annotation coverage, this is inadequate.
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 extremely concise at just three words, with zero wasted language. It's front-loaded with the essential information and doesn't contain any unnecessary elaboration. This is an excellent example of efficient communication.
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 lack of annotations and output schema, the description is insufficiently complete. For a search tool that likely returns structured results, the description doesn't explain what kind of results to expect (videos, playlists, channels), what fields are returned, or how results are ordered. The description also fails to address the relationship with the sibling 'search_youtube' tool, creating ambiguity about tool selection.
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 100%, so the schema already fully documents both parameters (query and maxResults). The description doesn't add any parameter-specific information beyond what's in the schema. According to scoring rules, when schema coverage is high (>80%), the baseline is 3 even with no param info in the description.
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 action ('Search') and target resource ('YouTube for music'), providing a specific verb+resource combination. However, it doesn't distinguish this tool from the sibling 'search_youtube' tool, which appears to be a more general search function. The description 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 a sibling tool named 'search_youtube' that appears to serve a similar function, there's no indication of when to choose the music-specific search versus the general search. No usage context, exclusions, or prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_youtubeC
Search YouTube
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Search query | |
| maxResults | No | Maximum results (1-50, default: 10) |
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 but offers none. It doesn't mention whether this is a read-only operation, what permissions might be needed, rate limits, pagination behavior, or what format results return. For a search tool with no annotation coverage, this complete lack of behavioral information is inadequate.
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 maximally concise at just two words, with zero wasted language. While this conciseness comes at the expense of completeness, the description is perfectly front-loaded and contains no unnecessary verbiage. Every word earns its place, even if more content would be beneficial.
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 a search operation with no annotations and no output schema, the description is insufficiently complete. While the schema covers parameters well, the description doesn't explain what the tool actually returns (video results? metadata?), how results are structured, or any behavioral characteristics. For a search tool with rich sibling alternatives, more context is needed.
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 provides no parameter information whatsoever, but the input schema has 100% description coverage with clear documentation for both parameters (query and maxResults). Since schema_description_coverage is high (>80%), the baseline score of 3 applies even without parameter details in the description. The schema adequately documents what each parameter does.
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 'Search YouTube' is essentially a tautology that restates the tool name without adding meaningful specificity. It doesn't clarify what kind of search this performs (videos, channels, playlists?), what scope it covers, or how it differs from sibling tools like search_music. While the verb 'search' is clear, the resource 'YouTube' is too broad without further qualification.
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 absolutely no guidance about when to use this tool versus alternatives. With sibling tools like search_music, get_video_info, and detect_topics available, there's no indication whether this is for general video search, how it differs from search_music, or what contexts warrant its use. The description offers zero usage context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
summarize_videoC
Generate AI summary of video
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | YouTube video URL | |
| maxWords | No | Maximum words in summary (default: 200) |
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 but offers minimal information. It states what the tool does ('Generate AI summary') but doesn't describe how it works, what kind of summary is produced, whether it requires internet access, processing time, rate limits, or authentication needs. This leaves significant gaps in understanding 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 extremely concise with just four words, front-loading the core purpose without any wasted language. Every word earns its place by directly contributing to understanding the tool's function.
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 summarization and the lack of annotations and output schema, the description is insufficiently complete. It doesn't explain what the summary output looks like, format, limitations, or how it differs from other video tools. For a tool with no structured behavioral data, more descriptive context is needed.
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 input schema has 100% description coverage, clearly documenting both parameters ('url' as YouTube video URL and 'maxWords' with default). The description adds no additional parameter semantics beyond what the schema provides, so it meets the baseline score of 3 for adequate schema coverage without extra value from the description.
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 ('Generate') and resource ('AI summary of video'), making it immediately understandable. However, it doesn't explicitly differentiate this tool from sibling tools like 'generate_video_highlights' or 'get_transcript', which might also produce video-related summaries or content.
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 this summary generation is preferred over other video analysis tools like 'detect_topics' or 'generate_chapters', nor does it specify 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.
translate_transcriptC
Translate video transcript
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | YouTube video URL | |
| targetLanguage | Yes | Target language |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states the action but doesn't disclose behavioral traits such as whether it requires internet access, how it handles errors (e.g., invalid URLs), rate limits, or output format (e.g., text, file). This leaves significant gaps for an AI agent to understand how to invoke it correctly.
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 extremely concise with just three words, front-loaded and zero waste. Every word earns its place by directly stating the tool's function without unnecessary elaboration.
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 (translation tool with 2 parameters) and lack of annotations and output schema, the description is incomplete. It doesn't explain what the tool returns (e.g., translated text, error messages), behavioral aspects, or usage context, making it inadequate for an AI agent to fully understand the tool's operation.
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 100%, so the schema already documents both parameters ('url' as YouTube video URL and 'targetLanguage' as target language). The description adds no additional meaning beyond this, such as examples (e.g., language codes) or constraints (e.g., supported languages), resulting in a baseline score of 3.
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 'Translate video transcript' states the verb (translate) and resource (video transcript), providing a basic purpose. However, it lacks specificity about what kind of translation (e.g., full transcript, partial, format) and doesn't distinguish from siblings like 'get_transcript' or 'summarize_video', making it vague in context.
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?
No guidance is provided on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing a transcript first), exclusions, or how it relates to siblings like 'get_transcript' (which might fetch the transcript) or 'summarize_video' (which might process it differently).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
14 tool updates
v1.0.0- First observed
detect_topics - First observed
download_thumbnail - First observed
generate_chapters - First observed
generate_video_highlights - First observed
get_channel_info - First observed
get_keywords - First observed
get_playlist_info - First observed
get_transcript - First observed
get_video_info - First observed
play_youtube_video - First observed
search_music - First observed
search_youtube - First observed
summarize_video - First observed
translate_transcript
TDQS
Scored across 14 tools
Each tool has a clearly distinct purpose targeting specific YouTube-related actions or resources, such as detecting topics, downloading thumbnails, generating chapters/highlights, getting various types of information, searching, summarizing, and translating. There is no significant overlap or ambiguity between tools, making it easy for an agent to select the appropriate one.
All tool names follow a consistent verb_noun pattern using snake_case, such as 'detect_topics', 'download_thumbnail', 'get_channel_info', and 'search_youtube'. This uniformity enhances readability and predictability across the entire tool set.
With 14 tools, the server is well-scoped for YouTube content analysis and interaction, covering a comprehensive range of operations from information retrieval to AI-powered processing. Each tool serves a unique and justified function within this domain.
The tool set provides complete coverage for YouTube video and channel analysis, including CRUD-like operations (e.g., get info, search), AI enhancements (e.g., summarize, generate highlights), and utility functions (e.g., play video, translate transcript). There are no obvious gaps that would hinder agent workflows in this domain.
Maintenance
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.
Extract YouTube transcripts, search what was said, and read on-screen frames with cited timestamps.
Transcribe YouTube via Whisper. Summaries, chapters, semantic-search across your corpus.
Related MCP Servers
- AlicenseBqualityDmaintenanceTransforms YouTube into a queryable knowledge source with search, video details, transcript analysis, and AI-powered tools for summaries, learning paths, and knowledge graphs. Features quota-aware API access with caching and optional OpenAI/Anthropic integration for advanced content analysis.101871MIT
- 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
- AlicenseAqualityDmaintenanceEnables AI tools to access YouTube content, including transcript extraction, video/channel info, and search.414MIT
- AlicenseAqualityDmaintenanceEnables fetching, searching, and summarizing YouTube video transcripts with multi-language support.4MIT