Extract YouTube video transcripts, comments, video info, and search results.
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 Data MCP Server get transcript for https://youtube.com/watch?v=dQw4w9WgXcQ"
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.
A Model Context Protocol (MCP) server for extracting YouTube video transcripts, comments, and search results. Supports both Stdio and StreamableHTTP transports.
getTranscript - Extract subtitles/transcripts with optional timestamps
getVideoInfo - Get video metadata (title, views, comments count)
getComments - Fetch comments with pagination and sorting
getCommentReplies - Get replies to specific comments
searchYoutube - Search videos, channels, and playlists
Related MCP server: youtube-summarize
Dual Transport: Stdio (default) + StreamableHTTP for web integration
Reliable Transcripts: Replaced youtube-transcript with youtube-caption-extractor (bot detection bypass, serverless support)
Timestamp Support: Optional start time and duration for each transcript segment
Modular Architecture: Clean separation of concerns (config, types, services, tools)
MCP SDK v1.25.2: Latest SDK with improved stability
Node.js 18+
SerpAPI key (for search, comments, video info)
git clone https://github.com/diasm3/serpapi-youtube-mcp-server.git
cd serpapi-youtube-mcp-server
npm installCreate a .env file:
SERPAPI_KEY=your_serpapi_key_here
PORT=3000 # optional, for HTTP modeGet your SerpAPI key at serpapi.com.
# Build
npm run build
# Stdio mode (default) - for Claude Desktop, Cursor, etc.
npm start
# HTTP mode - for web applications
npm start -- --http
# or
MCP_TRANSPORT=http npm startWhen running in HTTP mode:
GET /health - Health check
POST /mcp - MCP request handler
{
"mcpServers": {
"youtube-data": {
"command": "node",
"args": ["/path/to/serpapi-youtube-mcp-server/build/index.js"],
"env": {
"SERPAPI_KEY": "your_serpapi_key_here"
}
}
}
}{
"mcpServers": {
"youtube-data": {
"command": "npx",
"args": ["-y", "youtube-data-mcp"],
"env": {
"SERPAPI_KEY": "your_serpapi_key_here"
}
}
}
}Extract transcript/subtitles from a YouTube video.
Parameter | Type | Required | Description |
| string | Yes | YouTube URL or video ID |
| string | No | Language code (default: 'en') |
| boolean | No | Include start/duration per segment |
Get the Korean transcript for https://youtube.com/watch?v=xxxxx with timestampsGet video metadata using SerpAPI.
Parameter | Type | Required | Description |
| string | Yes | YouTube URL or video ID |
Returns: title, views, publish date, channel, comment count, pagination tokens
Fetch video comments with pagination.
Parameter | Type | Required | Description |
| string | Conditional | Required for first page |
| number | No | Max comments (default: 100) |
| string | No | 'relevance' or 'time' |
| string | No | For pagination |
Get replies to a specific comment.
Parameter | Type | Required | Description |
| string | Yes |
|
Search YouTube for videos, channels, playlists.
Parameter | Type | Required | Description |
| string | Yes | Search query |
| number | No | Max results (default: 10) |
| string | No | Country code (us, kr, jp) |
| string | No | Language code (en, ko, ja) |
| string | No | Filter parameter |
| string | No | For pagination |
src/
├── index.ts # Server entry (Stdio + HTTP)
├── config/ # Environment configuration
├── types/ # Zod schemas + TypeScript types
├── services/
│ ├── serpapi.ts # SerpAPI integration
│ └── youtube.ts # Transcript extraction
├── tools/ # MCP tool definitions
└── utils/ # Helper functionsSome videos don't have captions enabled
Try different language codes (en, ko, ja, etc.)
Auto-generated captions may not be available for all videos
Verify your API key is valid
Check your SerpAPI quota/limits
Ensure the video is publicly accessible
Check if PORT is already in use
Verify environment variables are set
MIT
Fetch replies to a specific YouTube comment. Use repliesToken from getComments response.
| Name | Required | Description | Default |
|---|---|---|---|
| pageToken | Yes | repliesToken from a comment object |
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 mentions the token source but does not disclose response format, pagination, error behavior, or any side effects. For a tool with no annotations, 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 two short sentences, each earning its place. It is front-loaded with the main verb and resource, and the second sentence provides a necessary usage hint. No wasted words.
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?
The tool is simple with one parameter and no output schema, but the description does not specify the return format or any pagination limits. It does establish the key integration step (using repliesToken from getComments), which is essential context. However, for a tool without an output schema, the description could be more explicit about what is returned.
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 parameter schema already provides 100% coverage for pageToken with a clear description. The description adds value by linking the token to getComments response, reinforcing the meaning beyond the schema. This extra context justifies a score above the baseline 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 uses a specific verb ('Fetch') and resource ('replies to a specific YouTube comment'), which clearly distinguishes it from siblings like getComments (top-level comments) and getTranscript. The purpose is unambiguous and directly communicates the tool's function.
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 instruction 'Use repliesToken from getComments response' provides clear context on how to use the tool, implying it should be called after getComments. It does not explicitly state when-not-to-use or name alternatives, but the dependency on getComments is clearly conveyed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch YouTube video comments with pagination. Supports sorting by relevance or time. Use nextPageToken for pagination.
| Name | Required | Description | Default |
|---|---|---|---|
| url | No | YouTube video URL or ID (required for first page) | |
| sort | No | Sort: relevance or time | relevance |
| limit | No | Max comments to return (1-100) | |
| pageToken | No | Pagination token from previous response |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses pagination via nextPageToken and sorting options, but does not mention whether top-level comments only are returned, response structure, or rate limits. Some behavioral context is provided, but gaps remain.
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 two sentences with no fluff. It front-loads the main purpose, then adds key features (sorting) and a usage note (pagination). Every sentence earns 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?
No output schema exists, so the description should explain return values. It mentions nextPageToken but does not describe the comment list structure or clarify scope (top-level vs all comments). The description is adequate but leaves some gaps for an agent relying solely on it.
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 covers all parameters with descriptions, so the baseline is 3. The description repeats pagination and sorting but adds no new meaning beyond the schema, which already provides detailed parameter descriptions.
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 fetches YouTube video comments with pagination, using a specific verb and resource. It distinguishes itself from siblings like getTranscript (transcripts) and getCommentReplies (replies) by focusing on comments and pagination.
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 implies usage for retrieving video comments but does not explicitly mention alternatives or exclusions (e.g., 'for replies, use getCommentReplies'). Context is present but no direct comparison to sibling tools, so it remains at an implied level.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Extract transcript/subtitles from a YouTube video. Returns full text with video metadata. Supports multiple languages and optional timestamps.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | YouTube video URL or 11-character video ID | |
| lang | No | Language code (en, ko, ja, es, etc.) | en |
| includeTimestamps | No | Include start time and duration for each segment |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of behavioral disclosure. It states that it returns full text with video metadata and supports languages/timestamps, but it does not mention edge cases such as videos without captions or whether the operation is read-only.
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 two concise sentences, front-loaded with the main purpose and followed by return and feature details. Every sentence earns its place with no unnecessary filler.
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 there is no output schema, the description should more fully explain return values and error behavior. It mentions full text and video metadata but omits specific fields, failure modes, and handling of unavailable subtitles, making it minimally adequate.
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 covers all three parameters with descriptions, so the baseline is 3. The description adds minimal extra semantic value beyond the schema, only alluding to language support and optional timestamps.
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 extracts transcript/subtitles from a YouTube video, with a specific verb and resource. It is easily distinguished from sibling tools like getVideoInfo and getComments.
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 use case is clear from the description: use this when you need the transcript or subtitles of a YouTube video. However, it does not explicitly mention alternatives or when not to use this tool, so it falls just short of full guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get YouTube video metadata: title, views, publish date, channel, comment count, and pagination tokens for comments.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | YouTube video URL or video ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosing behavior. It lists the return fields and mentions pagination tokens, but does not clarify that comment content is not included, nor does it address error handling, authentication, or rate limits. The description provides basic information but lacks depth.
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 is front-loaded with the primary purpose ('Get YouTube video metadata') and follows with specific details. No wasted words; it earns 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?
The description adequately covers the key metadata fields and mentions pagination tokens, which is useful for a video info tool. However, it does not explain how the pagination tokens relate to sibling comment tools, nor does it mention any output structure or potential limitations. It is complete enough for simple usage but lacks some contextual depth.
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 fully documents the sole parameter 'url' with a clear description ('YouTube video URL or video ID'), so the schema already provides the necessary semantic meaning. The tool description adds no extra parameter context beyond what the schema offers, aligning with the baseline score of 3 for high schema coverage.
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 retrieves YouTube video metadata and lists specific fields (title, views, publish date, channel, comment count). This distinguishes it from sibling tools like getTranscript, getComments, and searchYoutube, which cover different aspects.
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 implies the tool is for fetching video metadata, but it does not explicitly say when to use this tool over getComments or getTranscript, nor does it mention exclusions like 'use getComments for actual comment text'. The usage context is implied rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search YouTube for videos, channels, and playlists. Returns results with thumbnails, views, and channel info.
| Name | Required | Description | Default |
|---|---|---|---|
| gl | No | Country code (us, kr, jp) | |
| hl | No | Language code (en, ko, ja) | |
| sp | No | Filter parameter for duration/date | |
| limit | No | Max results (1-50) | |
| query | Yes | Search query | |
| pageToken | No | Pagination token |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that the search covers multiple resource types and that results include thumbnails, views, and channel info. However, it omits behavioral details like pagination (despite a `pageToken` parameter), result limits, and the non-destructive nature of the operation, leaving gaps in transparency.
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 two concise sentences that front-load the core purpose ('Search YouTube for videos, channels, and playlists') followed by return value information. There is no filler, redundancy, or wasted wording, making it optimally concise.
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?
The description provides a clear overall purpose and return information, and the schema covers all parameters. However, it lacks contextual details about pagination, how to use the `sp` filter for duration/date, and the relationship to sibling tools. Since there is no output schema, the return-field mention helps, but the tool is not fully contextualized.
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 coverage is 100%, with all six parameters having descriptions in the schema. The description adds no extra parameter semantics beyond what the schema already provides—it does not elaborate on `gl`, `hl`, `sp`, `limit`, or `pageToken`. Baseline 3 is appropriate when 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 uses a specific verb 'Search' with resource 'YouTube' and explicitly lists the result types ('videos, channels, and playlists') and return fields ('thumbnails, views, and channel info'). This clearly distinguishes it from sibling tools like getVideoInfo and getComments, which retrieve specific resources.
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 states what the tool does but does not explicitly tell the agent when to use this tool versus alternatives like getVideoInfo or getComments. The sibling names imply a search-to-detail workflow, but no explicit 'use this for X, use that for Y' guidance is provided, so usage is only implied.
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.
v2.0.0getCommentRepliesgetCommentsgetTranscriptgetVideoInfosearchYoutubeEach tool targets a distinct YouTube data aspect: transcript, video metadata, comments, comment replies, and search. There is no overlap or ambiguity between them.
Four tools follow a consistent 'get' + noun pattern (getTranscript, getVideoInfo, getComments, getCommentReplies), but searchYoutube deviates by using a verb-noun phrase. The pattern is mostly consistent and readable.
With 5 tools, the server is well-scoped for YouTube data retrieval. Each tool serves a clear and necessary function without excessive granularity or missing core operations.
The tool set covers major YouTube data retrieval needs: search, video info, transcript, comments, and replies. Minor gaps exist (e.g., playlist or channel details) but the core workflows are well supported.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
YouTube MCP — wraps the YouTube Data API v3 (BYO API key)
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.
Search YouTube, read video metadata, and fetch transcripts with language preferences
Hosted MCP for YouTube Studio: uploads, metadata, playlists, comments, analytics, captions.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/diasm3/serpapi-youtube-mcp-server'
If you have feedback or need assistance with the MCP directory API, please join our Discord server