This server provides MCP tools for extracting and formatting YouTube video transcripts, with multiple transports and deployment options.
Extract a single video's transcript in text, JSON, or SRT format (get_transcript)
Bulk extract transcripts from multiple YouTube videos (get_bulk_transcripts)
Extract transcripts from all videos in a playlist (get_playlist_transcripts) — though playlist support is unfinished
Convert existing transcript data between text, JSON, and SRT formats (format_transcript)
List all available transcripts for a video (list_transcripts)
View cache statistics (get_cache_stats) and clear the cache (clear_cache)
Run as an MCP server over stdio, SSE, or HTTP transports
Supports language selection for transcripts
Deployable via Docker and npm package, with caching, rate limiting, and configuration options
Offers full containerization support with Docker deployment options, including health checks, Docker Compose configuration, and container registry distribution via GitHub Container Registry.
Integrates with ESLint for code style enforcement and quality control in the development workflow.
Integrates with GitHub for issue tracking, documentation hosting, and container registry distribution through GitHub Container Registry.
Distributed as an npm package for easy installation and integration, with both global CLI usage and programmatic API access.
Built with TypeScript for full type safety, providing strongly-typed interfaces for transcript data and programmatic usage of the service.
Extracts and processes YouTube video transcripts with support for single videos, bulk processing, and playlists. Provides transcript data in multiple formats (text, JSON, SRT) and supports multi-language extraction.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@YouTube Transcript DL MCP Server get transcript for https://youtu.be/dQw4w9WgXcQ in English"
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.
Deprecated and incomplete: the published package does not contain every runtime dependency used by the repository, playlist extraction is unfinished, and the test suite is not fully passing. Do not use this as a production MCP server. The package remains available only for historical compatibility.
A comprehensive MCP (Model Context Protocol) server for extracting YouTube video transcripts with support for multiple transports (stdio, SSE, HTTP), Docker deployment, and npm package distribution.
🎯 Multiple Transport Support: stdio, Server-Sent Events (SSE), and HTTP
📹 Transcript Extraction: Single-video extraction; playlist support is unfinished
🌍 Multi-language Support: Extract transcripts in different languages
📝 Multiple Output Formats: Text, JSON, and SRT subtitle formats
🚀 High Performance: Built-in caching and rate limiting
🐳 Docker Ready: Full containerization support
📦 npm Package: Easy installation and distribution
🧪 Test Suite: Partial coverage; not all tests currently pass
🔧 TypeScript: Full type safety and modern JavaScript features
Related MCP server: youtube-mcp
npm install -g yt-transcript-dl-mcpgit clone https://github.com/jedarden/yt-transcript-dl-mcp.git
cd yt-transcript-dl-mcp
npm install
npm run build# From GitHub Container Registry (recommended)
docker pull ghcr.io/jedarden/yt-transcript-dl-mcp:latest
docker run -p 3001:3001 -p 3002:3002 ghcr.io/jedarden/yt-transcript-dl-mcp:latest --multi-transport
# Build from source
docker build -t yt-transcript-dl-mcp .
docker run -p 3001:3001 -p 3002:3002 yt-transcript-dl-mcp --multi-transportStart the MCP server in different modes:
# Stdio mode (default)
yt-transcript-dl-mcp start
# SSE mode
yt-transcript-dl-mcp start --transport sse --port 3000
# HTTP mode
yt-transcript-dl-mcp start --transport http --port 3000
# With verbose logging
yt-transcript-dl-mcp start --verboseTest the server with a sample video:
# Test with a YouTube video
yt-transcript-dl-mcp test dQw4w9WgXcQ
# Test with different language
yt-transcript-dl-mcp test dQw4w9WgXcQ --language es
# Test with different format
yt-transcript-dl-mcp test dQw4w9WgXcQ --format srtimport { YouTubeTranscriptService } from 'yt-transcript-dl-mcp';
const service = new YouTubeTranscriptService();
// Extract single video transcript
const result = await service.getTranscript('dQw4w9WgXcQ', 'en', 'json');
console.log(result);
// Bulk processing
const bulkResult = await service.getBulkTranscripts({
videoIds: ['dQw4w9WgXcQ', 'jNQXAC9IVRw'],
outputFormat: 'json',
language: 'en'
});
console.log(bulkResult);The server provides the following MCP tools:
get_transcriptExtract transcript from a single YouTube video.
Parameters:
videoId (required): YouTube video ID or URL
language (optional): Language code (default: 'en')
format (optional): Output format - 'text', 'json', or 'srt' (default: 'json')
get_bulk_transcriptsExtract transcripts from multiple YouTube videos.
Parameters:
videoIds (required): Array of YouTube video IDs or URLs
language (optional): Language code (default: 'en')
outputFormat (optional): Output format - 'text', 'json', or 'srt' (default: 'json')
includeMetadata (optional): Include metadata in response (default: true)
get_playlist_transcriptsExtract transcripts from all videos in a YouTube playlist.
Parameters:
playlistId (required): YouTube playlist ID or URL
language (optional): Language code (default: 'en')
outputFormat (optional): Output format - 'text', 'json', or 'srt' (default: 'json')
includeMetadata (optional): Include metadata in response (default: true)
format_transcriptFormat existing transcript data into different formats.
Parameters:
transcript (required): Transcript data array
format (required): Output format - 'text', 'json', or 'srt'
get_cache_statsGet cache statistics and performance metrics.
clear_cacheClear the transcript cache.
# Server configuration
PORT=3000
HOST=0.0.0.0
MCP_TRANSPORT=stdio
# CORS settings
CORS_ENABLED=true
CORS_ORIGINS=*
# Rate limiting
RATE_LIMIT_WINDOW=900000 # 15 minutes in ms
RATE_LIMIT_MAX=100
# Caching
CACHE_ENABLED=true
CACHE_TTL=3600 # 1 hour in seconds
CACHE_MAX_SIZE=1000
# Logging
LOG_LEVEL=info
LOG_FORMAT=simpleCreate a config.json file:
{
"port": 3000,
"host": "0.0.0.0",
"cors": {
"enabled": true,
"origins": ["*"]
},
"rateLimit": {
"windowMs": 900000,
"max": 100
},
"cache": {
"enabled": true,
"ttl": 3600,
"maxSize": 1000
},
"logging": {
"level": "info",
"format": "simple"
}
}version: '3.8'
services:
yt-transcript-mcp:
build: .
ports:
- "3000:3000"
environment:
- NODE_ENV=production
- PORT=3000
- LOG_LEVEL=info
restart: unless-stopped
healthcheck:
test: ["CMD", "node", "dist/health-check.js"]
interval: 30s
timeout: 10s
retries: 3The Docker container includes built-in health checks:
# Check container health
docker ps
docker exec <container-id> node dist/health-check.jsgit clone <repository-url>
cd yt-transcript-dl-repo
npm install# Run all tests
npm test
# Run tests with coverage
npm run test:coverage
# Run specific test suites
npm run test:unit
npm run test:integration
npm run test:e2e
# Watch mode
npm run test:watch# Build TypeScript
npm run build
# Development mode with watch
npm run dev
# Linting
npm run lint
npm run lint:fix# Test stdio transport
./scripts/test-stdio.sh
# Test with sample video
npm run test:sampleAll transcript responses follow this structure:
interface TranscriptResponse {
videoId: string;
title?: string;
language: string;
transcript: TranscriptItem[];
metadata?: {
extractedAt: string;
source: string;
duration?: number;
error?: string;
};
}
interface TranscriptItem {
text: string;
start: number;
duration: number;
}The server handles various error scenarios:
Video not found: Returns empty transcript with error in metadata
Private videos: Graceful error handling with descriptive messages
Rate limiting: Built-in delays and retry logic
Network errors: Automatic retries with exponential backoff
Single video extraction: < 5 seconds
Bulk processing: < 2 seconds per video
Concurrent requests: 90%+ success rate for 10 concurrent requests
Memory usage: < 512MB under normal load
Cache hit ratio: 70%+ for repeated requests
LRU Cache: Configurable TTL and size limits
Rate Limiting: Prevents API abuse
Concurrent Processing: Optimized for bulk operations
Memory Management: Efficient garbage collection
Video not found: Check if video is public and has captions
Rate limiting: Reduce concurrent requests or increase delays
Memory issues: Reduce cache size or clear cache regularly
Network errors: Check internet connection and firewall settings
Enable debug logging:
export LOG_LEVEL=debug
yt-transcript-dl-mcp start --verboseCheck logs in the logs/ directory:
tail -f logs/combined.log
tail -f logs/error.logFork the repository
Create a feature branch
Write tests for new functionality
Ensure all tests pass
Submit a pull request
Use TypeScript for all code
Follow ESLint configuration
Write comprehensive tests
Add JSDoc comments for public APIs
Use conventional commit messages
MIT License - see LICENSE file for details.
GitHub Issues: Report bugs and feature requests
Documentation: Full API documentation
Examples: Usage examples
Initial release
MCP server with stdio, SSE, and HTTP transports
Single video and bulk transcript extraction
Docker containerization
Comprehensive test suite
TypeScript support
Caching and rate limiting
Multiple output formats (text, JSON, SRT)
Clear the transcript cache
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
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. 'Clear' implies a destructive mutation, but the description doesn't specify whether this is reversible, what permissions are needed, or what happens to system performance. It lacks details on rate limits, side effects, or return values, which is a significant gap for a mutation tool.
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 no wasted words. It's front-loaded and directly states the tool's purpose, making it highly concise and well-structured 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 complexity of a destructive cache-clearing operation with no annotations and no output schema, the description is incomplete. It doesn't explain behavioral aspects like safety, permissions, or what to expect after execution, which are critical for such a tool.
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 0 parameters with 100% coverage, so no parameter documentation is needed. The description doesn't add parameter details, which is appropriate, earning a baseline score of 4 for tools with no parameters.
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 'Clear the transcript cache' clearly states the action (clear) and target resource (transcript cache). It uses a specific verb and identifies the resource, though it doesn't explicitly differentiate from sibling tools like 'get_cache_stats' or 'list_transcripts' beyond the action type.
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, consequences, or relationships to sibling tools like 'get_cache_stats' for monitoring or 'list_transcripts' for accessing cached data, leaving usage context unclear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Format existing transcript data into different formats
| Name | Required | Description | Default |
|---|---|---|---|
| transcript | Yes | Transcript data to format | |
| format | Yes | Output format | json |
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 tool formats data but doesn't disclose behavioral traits such as whether it's read-only, if it modifies input data, performance characteristics, or error handling. This is a significant gap for a tool with no annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose without waste. It's appropriately sized for the tool's complexity, with every word earning its place.
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, no output schema, and 2 parameters with full schema coverage, the description is minimally adequate. It states the purpose but lacks behavioral context and output details, making it incomplete for a formatting tool that might have side effects or specific return formats.
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 both parameters well-documented in the schema. The description adds no additional meaning beyond the schema, such as explaining format details or transcript structure. Baseline 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 clearly states the verb 'format' and the resource 'existing transcript data', specifying it transforms data into different formats. It distinguishes from siblings like 'get_transcript' or 'list_transcripts' by focusing on formatting rather than retrieval, though it doesn't explicitly name alternatives for 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. It doesn't mention prerequisites (e.g., needing transcript data first), exclusions, or compare with siblings like 'get_bulk_transcripts' for bulk operations. Usage is implied but not specified.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Extract transcripts from multiple YouTube videos
| Name | Required | Description | Default |
|---|---|---|---|
| videoIds | Yes | Array of YouTube video IDs or URLs | |
| language | No | Language code (e.g., "en", "es", "fr") | en |
| outputFormat | No | Output format | json |
| includeMetadata | No | Include metadata in response |
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 but only states the basic operation. It doesn't mention whether this is a read-only operation, potential rate limits, authentication requirements, error handling (e.g., for invalid video IDs), or what happens when transcripts are unavailable. For a bulk operation tool with zero annotation coverage, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that gets straight to the point with zero wasted words. It's appropriately sized for a tool with clear parameters documented elsewhere and follows good front-loading principles.
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 bulk operation tool with 4 parameters, no annotations, and no output schema, the description is incomplete. It doesn't explain the return format, error conditions, performance characteristics, or how results are structured for multiple videos. The agent would need to guess about important behavioral aspects.
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 doesn't add any parameter-specific information beyond what's already in the schema (which has 100% coverage). It doesn't explain relationships between parameters, provide examples, or clarify semantics like what 'includeMetadata' actually includes. With high schema coverage, the baseline is 3, but no additional value is added.
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 ('Extract transcripts') and resource ('from multiple YouTube videos'), making the purpose immediately understandable. However, it doesn't explicitly differentiate from sibling tools like 'get_transcript' (single video) or 'get_playlist_transcripts' (playlist-based), which would be needed for 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_transcript' (single video) or 'get_playlist_transcripts' (playlist-based). It also doesn't mention prerequisites, rate limits, or error conditions, leaving the agent with insufficient context for optimal tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get cache statistics and performance metrics
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
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' implies a read operation, the description doesn't specify whether this requires authentication, what format the statistics are returned in, or if there are any rate limits. This leaves significant gaps for a tool with zero 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 any fluff or redundancy. It's 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 that there are no annotations and no output schema, the description is incomplete. It doesn't explain what 'cache statistics and performance metrics' include, how they're formatted, or any behavioral aspects like error handling. For a tool with zero structured metadata, this minimal description leaves too many 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?
The tool has 0 parameters, and the schema description coverage is 100%, so there's no need for parameter details in the description. The baseline for this scenario is 4, as the description appropriately doesn't waste space on non-existent parameters.
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 the resource ('cache statistics and performance metrics'), making the purpose immediately understandable. However, it doesn't differentiate this tool from its sibling tools (like clear_cache or format_transcript), which would be needed for a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention any context, prerequisites, or exclusions, leaving the agent to infer usage based on 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.
Extract transcripts from all videos in a YouTube playlist
| Name | Required | Description | Default |
|---|---|---|---|
| playlistId | Yes | YouTube playlist ID or URL | |
| language | No | Language code (e.g., "en", "es", "fr") | en |
| outputFormat | No | Output format | json |
| includeMetadata | No | Include metadata in response |
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 but offers minimal information. It states what the tool does ('Extract transcripts') but doesn't describe how it behaves - no mention of rate limits, authentication requirements, error handling, processing time, or what happens with invalid playlist IDs. For a tool that likely makes external API calls, 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 a single, focused sentence that efficiently communicates the core functionality without unnecessary words. It's front-loaded with the main action and resource, making it immediately scannable and easy to understand at a glance.
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 4 parameters, no annotations, and no output schema, the description is insufficiently complete. It doesn't explain what the output looks like (especially important with format options), doesn't mention error conditions or limitations, and provides no context about the extraction process. The agent would need to guess about many behavioral aspects.
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 all parameters are documented in the schema itself. The description doesn't add any parameter-specific information beyond what's in the schema (e.g., it doesn't explain what 'includeMetadata' actually includes or provide examples of playlist ID formats). This meets the baseline for high schema coverage but doesn't enhance understanding.
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 ('Extract transcripts') and target resource ('from all videos in a YouTube playlist'), making the purpose immediately understandable. However, it doesn't explicitly differentiate from sibling tools like 'get_transcript' (single video) or 'get_bulk_transcripts' (multiple videos), which would require more specific scoping language to achieve 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_transcript' for single videos or 'get_bulk_transcripts' for multiple videos without playlist context. There's no mention of prerequisites, limitations, or typical use cases, 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.
Extract transcript from a single YouTube video
| Name | Required | Description | Default |
|---|---|---|---|
| videoId | Yes | YouTube video ID or URL | |
| language | No | Language code (e.g., "en", "es", "fr") | en |
| format | No | Output format | json |
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 action ('Extract') but doesn't describe what happens if the video lacks a transcript, rate limits, authentication needs, error handling, or the structure of the output. For a tool with no annotation coverage, this leaves significant gaps in understanding its 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, efficient sentence with zero waste. It's front-loaded with the core purpose and appropriately sized for the tool's complexity, 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 tool's moderate complexity (3 parameters, no output schema, no annotations), the description is incomplete. It lacks information on output format details, error cases, or behavioral traits. Without annotations or an output schema, the description should do more to compensate, such as explaining what the extracted transcript looks like or common pitfalls.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds no parameter semantics beyond what the input schema provides. Since schema description coverage is 100%, the schema already documents videoId, language, and format with descriptions and defaults. The baseline score of 3 is appropriate as the schema does the heavy lifting, but the description doesn't enhance understanding of parameter usage.
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 ('Extract') and resource ('transcript from a single YouTube video'), distinguishing it from siblings like get_bulk_transcripts (multiple videos) and get_playlist_transcripts (playlist). However, it doesn't explicitly differentiate from format_transcript, which might be for post-processing rather than extraction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention when to choose get_transcript over get_bulk_transcripts for multiple videos, or when format_transcript might be needed for processing. There's no context about prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all available transcripts for a YouTube video
| Name | Required | Description | Default |
|---|---|---|---|
| videoId | Yes | YouTube video ID or URL |
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 ('List all available transcripts') but doesn't describe what 'available' means (e.g., language options, format types), whether there are rate limits, authentication needs, or how results are returned (e.g., pagination, 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, clear sentence that directly states the tool's purpose without any wasted words. It is front-loaded and efficiently communicates the core functionality, 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. It doesn't explain what 'available transcripts' entails (e.g., multiple languages, formats), behavioral traits like rate limits, or how to interpret results. For a tool that likely returns a list of transcripts, more context is needed to guide 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 'videoId' documented as 'YouTube video ID or URL'. The description adds no additional meaning beyond this, such as examples of valid IDs or URL formats. Since the schema does the heavy lifting, the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('List') and resource ('all available transcripts for a YouTube video'), making the purpose immediately understandable. However, it doesn't distinguish this tool from sibling tools like 'get_transcript' or 'get_bulk_transcripts', which likely have overlapping functionality but different scopes or outputs.
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 such as 'get_transcript' (which might fetch a single transcript) or 'get_bulk_transcripts' (which could handle multiple videos). It lacks explicit when/when-not instructions or prerequisites, leaving usage context implied at best.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
clear_cacheformat_transcriptget_bulk_transcriptsget_cache_statsget_playlist_transcriptsget_transcriptlist_transcriptsEach tool has a clearly distinct purpose with no ambiguity: clear_cache handles cache management, format_transcript processes existing data, get_bulk_transcripts extracts from multiple videos, get_cache_stats provides metrics, get_playlist_transcripts targets playlists, get_transcript handles single videos, and list_transcripts enumerates available transcripts. The descriptions clearly differentiate between single-video, multi-video, playlist, cache, and formatting operations.
All tools follow a consistent verb_noun pattern with snake_case throughout: clear_cache, format_transcript, get_bulk_transcripts, get_cache_stats, get_playlist_transcripts, get_transcript, and list_transcripts. The naming is predictable and readable, using verbs like 'clear', 'format', 'get', and 'list' consistently across the set.
With 7 tools, the count is well-scoped for a YouTube transcript server, covering core operations like extraction (single, bulk, playlist), caching, formatting, and listing without bloat. Each tool earns its place by addressing a specific aspect of transcript handling, making the set neither too thin nor too heavy for the domain.
The tool surface is nearly complete for transcript extraction and management, covering key operations: extraction (single, bulk, playlist), cache management (clear, stats), formatting, and listing. A minor gap exists in update or delete operations for transcripts, but agents can work around this, and the core workflows are well-covered for the server's purpose.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
An MCP server that gives any LLM or agent clean YouTube transcripts on demand: a single video, a whole channel, or a playlist, plus AI cleanup of auto-generated captions. API-key auth, credit-based, same backend as the public v1 API. Get a free API key with 25 free credits at youtubetranscriptdownload.com/account.
An MCP server that provides tools to discover and retrieve podcast episodes transcripts.
MCP server for RiverScript, an AI transcription platform - fetches transcripts shared via a link.
An MCP server that provides congressional transcripts
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/jedarden/yt-transcript-dl-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
