Scrapes YouTube video search results, video details, channel info, playlists, and comments.
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-mcp search for latest music videos"
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.
This projectdoes not use the official YouTube Data API v3. It parses public web pages (ytInitialData). If YouTube changes its page structure, some features may break. Personal, non-commercial use is recommended.
Excessive requests may get blocked by YouTube. If that happens often, enable the Zyte proxy with theZYTE_API_KEY environment variable.
Related MCP server: mcp-apps
π Video search | Keyword search with sort, date, and duration filters |
πΊ Video details | Views, likes, duration, and more by ID or URL |
π‘ Channels | Look up channels by ID, @handle, or URL |
π Playlists | Playlist metadata and video lists |
π¬ Comments | Top and recent comments on a video |
π stdio MCP | Works with Cursor, Claude, Codex, and other local clients |
π No API key | No Google Cloud API key required |
git clone https://github.com/iamkw0n/youtube-mcp.git
cd youtube-mcp
npm install
npm run build
npm startOr run directly with tsx:
npx tsx src/index.tsTool | Description |
| Search videos by keyword |
| Get video details by ID or URL |
| Batch-fetch multiple videos |
| Search channels by keyword |
| Get channel info by ID, @handle, or URL |
| List recent videos from a channel |
| Get playlist metadata |
| List videos in a playlist |
| Fetch video comments |
| Check scraping and proxy status |
Paste this into Cursor, Claude Code, or Codex to ask the agent to install the MCP server:
Clone iamkw0n/youtube-mcp from GitHub and set up the MCP server for me.Client | Config file | stdio |
Cursor |
| β |
Claude Code |
| β |
Claude Desktop |
| β |
Codex |
| β |
ChatGPT | Connector URL | β |
Add to .cursor/mcp.json in your project root:
{
"mcpServers": {
"youtube-mcp": {
"command": "node",
"args": ["/absolute/path/to/youtube-mcp/dist/index.js"],
"cwd": "/absolute/path/to/youtube-mcp"
}
}
}With Zyte proxy (optional):
{
"mcpServers": {
"youtube-mcp": {
"command": "node",
"args": ["/absolute/path/to/youtube-mcp/dist/index.js"],
"cwd": "/absolute/path/to/youtube-mcp",
"env": {
"ZYTE_API_KEY": "${env:ZYTE_API_KEY}"
}
}
}
}Add to .mcp.json in your project root:
{
"mcpServers": {
"youtube-mcp": {
"type": "stdio",
"command": "node",
"args": ["/absolute/path/to/youtube-mcp/dist/index.js"]
}
}
}CLI:
claude mcp add youtube-mcp -s project -- node /absolute/path/to/youtube-mcp/dist/index.jsmacOS: ~/Library/Application Support/Claude/claude_desktop_config.json
Windows: %APPDATA%\Claude\claude_desktop_config.json
{
"mcpServers": {
"youtube-mcp": {
"command": "node",
"args": ["/absolute/path/to/youtube-mcp/dist/index.js"],
"cwd": "/absolute/path/to/youtube-mcp"
}
}
}Claude Desktop does not support${workspaceFolder}. Use absolute paths.
In .codex/config.toml or ~/.codex/config.toml:
[mcp_servers.youtube-mcp]
command = "node"
args = ["/absolute/path/to/youtube-mcp/dist/index.js"]
cwd = "/absolute/path/to/youtube-mcp"
enabled = trueCLI:
codex mcp add youtube-mcp -- node /absolute/path/to/youtube-mcp/dist/index.jsVerify in a Codex session with /mcp.
ChatGPT connectors only supportHTTPS MCP endpoints. This repo is a local stdio server and cannot be connected to ChatGPT directly.
Search YouTube for TypeScript tutorial videosGet details for this video: https://www.youtube.com/watch?v=dQw4w9WgXcQShow me the 5 most recent videos from @GoogleDevelopersWhat videos are in this playlist? https://www.youtube.com/playlist?list=PL...flowchart LR
A[MCP Client] -->|stdio| B[youtube-mcp]
B -->|fetch HTML| C[www.youtube.com]
B -->|parse| D[ytInitialData]
B -->|pagination| E[InnerTube continuation]Step | Description |
Page fetch | Download public YouTube HTML pages |
Data extraction | Parse |
Pagination | Load more results via InnerTube continuation tokens |
MIT Β© iamkw0n
YouTube μ€ν¬λν μν, μμ² νμ, Zyte νλ‘μ μ¬μ© μ¬λΆλ₯Ό νμΈν©λλ€.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. Description discloses the tool checks status, request count, and proxy usage but does not specify if it's read-only or any side effects. Some transparency, but could be improved.
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 concise sentence that is front-loaded with key information. No unnecessary 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?
Given the tool has no parameters and no output schema, the description adequately covers its purpose. Could mention that it requires no input, but overall complete enough.
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?
No parameters, so parameter semantics are not applicable. Baseline for 0 parameters is 4; the description does not need to add parameter info.
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 'νμΈν©λλ€' (check) and the resource (YouTube scraping status, request count, Zyte proxy usage). It distinguishes from sibling tools like get_channel or search_videos.
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 on when to use this tool versus alternatives. The description only states what it does without indicating context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
μ±λ ID, @νΈλ€, λλ URLλ‘ YouTube μ±λ μ 보λ₯Ό μ‘°νν©λλ€.
| Name | Required | Description | Default |
|---|---|---|---|
| channelIdOrHandleOrUrl | Yes | μ±λ ID (UC...), @νΈλ€, λλ YouTube μ±λ URL |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must convey behavior. It indicates a read operation but omits return fields, authentication requirements, or rate limits. Adequate but could detail output content.
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?
Single sentence, front-loaded with purpose, no extraneous words. Highly efficient.
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?
Tool is simple (1 param, no output schema). Description covers input and purpose but lacks output details. Minor gaps but generally complete for the low complexity.
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 parameter description explaining acceptable formats (UC... for ID, @handle, or URL). This adds guidance beyond the schema's string type. Slight improvement over baseline 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?
Description clearly states the verb (μ‘°νν©λλ€, 'retrieve') and resource (YouTube μ±λ μ 보, 'YouTube channel information'). It specifies three input types (ID, @handle, URL) and differs from siblings like search_channels and get_channel_videos.
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?
Implicitly suggests use when you have a channel identifier, but no explicit comparison to alternatives like search_channels or get_channel_videos. No guidance on when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
μ±λμ μ΅κ·Ό λμμ λͺ©λ‘μ μ‘°νν©λλ€.
| Name | Required | Description | Default |
|---|---|---|---|
| channelIdOrHandleOrUrl | Yes | μ±λ ID (UC...), @νΈλ€, λλ YouTube μ±λ URL | |
| maxResults | No | μ΅λ κ²°κ³Ό μ | |
| order | No | μ λ ¬ κΈ°μ€ | date |
| pageToken | No | λ€μ νμ΄μ§ ν ν° |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description only mentions 'recent videos' without explaining ordering (default date), pagination behavior, or any side effects. Since no annotations are present, the description carries the full burden but provides minimal behavioral context.
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, concise sentence that is front-loaded with the core purpose. It is not verbose, though it could include a bit more context without being excessive.
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 has 4 parameters including pagination, but the description omits details about return format, pagination mechanics, and what 'recent' implies. Given the complexity, this is incomplete for agent decision-making.
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%, and the description adds no extra meaning beyond what the schema already provides. The baseline of 3 is appropriate; the description does not enhance parameter 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 tool retrieves a list of recent videos for a channel, specifying the action and resource. However, it does not explicitly differentiate from sibling tools like search_videos or get_video, though the purpose is inferred.
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 (e.g., search_videos for broader search, get_video for single video). The agent receives no context for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
μ¬μλͺ©λ‘ ID λλ URLλ‘ YouTube μ¬μλͺ©λ‘ μ 보λ₯Ό μ‘°νν©λλ€.
| Name | Required | Description | Default |
|---|---|---|---|
| playlistIdOrUrl | Yes | μ¬μλͺ©λ‘ ID (PL...) λλ YouTube μ¬μλͺ©λ‘ 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. However, the description does not mention that this is a read-only operation, any required permissions, rate limits, or side effects. It only states the basic retrieval purpose.
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, concise sentence that immediately conveys the action. It is efficient and front-loaded with the key verb and resource, with no unnecessary information.
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 absence of an output schema and the simplicity of the tool, the description should at least hint at the type of information returned (e.g., title, description, item count). Without this, the agent cannot fully understand what the tool provides.
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 for the single parameter 'playlistIdOrUrl', which already explains it can be a playlist ID or URL. The description adds no additional semantic information beyond the schema, so 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 tool's purpose: to retrieve YouTube playlist information by ID or URL. It uses a specific verb ('μ‘°νν©λλ€' = retrieves) and resource ('μ¬μλͺ©λ‘ μ 보' = playlist information), and the distinction from sibling tools like 'get_playlist_items' (which fetches items) is implied.
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 does not explicitly state when to use this tool versus alternatives. It provides context that the tool accepts an ID or URL, but lacks guidance on when it is appropriate or when to use siblings like 'search_videos' or 'get_playlist_items'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
μ¬μλͺ©λ‘μ ν¬ν¨λ λμμ λͺ©λ‘μ μ‘°νν©λλ€.
| Name | Required | Description | Default |
|---|---|---|---|
| playlistIdOrUrl | Yes | μ¬μλͺ©λ‘ ID (PL...) λλ YouTube μ¬μλͺ©λ‘ URL | |
| maxResults | No | μ΅λ κ²°κ³Ό μ | |
| pageToken | No | λ€μ νμ΄μ§ ν ν° |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description only states 'retrieves list' without disclosing behavioral traits such as read-only nature, pagination support, or authentication requirements. Important details like maxResults limit (50) and pageToken mechanics are omitted.
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?
A single, front-loaded sentence efficiently conveys the core action with no wasted words. However, it may be too brief for a tool with multiple parameters and no output schema.
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 absence of annotations and output schema, the description is insufficient. It doesn't explain pagination, behavior of maxResults, or what the response contains. For a read tool with 3 parameters, 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?
Schema description coverage is 100%, so the schema already documents all parameters. The description adds no additional meaning beyond what the schema provides; it doesn't explain the format of playlistIdOrUrl or how pagination works.
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 'μ‘°νν©λλ€' (retrieves) and the resource 'μ¬μλͺ©λ‘μ ν¬ν¨λ λμμ λͺ©λ‘' (list of videos in playlist), distinguishing it from siblings like get_playlist (playlist metadata) and get_channel_videos (channel videos).
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 explicit guidance on when to use this tool versus alternatives like get_playlist or get_video. The description lacks context about prerequisites, scenarios, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
λμμ ID λλ URLλ‘ YouTube λμμ μμΈλ₯Ό μ‘°νν©λλ€.
| Name | Required | Description | Default |
|---|---|---|---|
| videoIdOrUrl | Yes | λμμ ID λλ YouTube URL (watch, youtu.be, shorts λ±) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description lacks behavioral details such as whether the operation is read-only (implied but not stated), error handling, rate limits, or authentication requirements. The only added behavior is that it accepts multiple URL formats, which is minimal.
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 concise sentence that delivers the core functionality without any redundant information.
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 low complexity (single parameter, no nested objects) and lack of output schema, the description is adequate but incomplete. It does not describe what 'details' are returned or mention any potential limitations.
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 for the single parameter is 100%, and the description adds value by listing supported URL formats (watch, youtu.be, shorts). This provides concrete examples beyond the schema's generic 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 verb (retrieve) and resource (YouTube video details), and specifies the input as video ID or URL. This distinguishes it from sibling tools like get_channel or get_videos which operate on different 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 provides no guidance on when to use this tool versus alternatives such as search_videos or get_videos. There are no explicit conditions, exclusions, or contextual recommendations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
λμμμ μΈκΈ° λκΈ λλ μ΅μ λκΈμ μ‘°νν©λλ€.
| Name | Required | Description | Default |
|---|---|---|---|
| videoIdOrUrl | Yes | λμμ ID λλ YouTube URL | |
| maxResults | No | μ΅λ κ²°κ³Ό μ | |
| order | No | μ λ ¬ (relevance: μΈκΈ°μ, time: μ΅μ μ) | relevance |
| pageToken | No | λ€μ νμ΄μ§ ν ν° |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It only states 'retrieves comments' but fails to disclose pagination behavior (though pageToken parameter exists), sorting semantics beyond schema, or that it likely returns only top-level comments. Lacks disclosure of any side effects or auth requirements.
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?
Single sentence, front-loaded with the main action. Efficient, but could be slightly more informative without being verbose. No 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?
With no output schema and no annotations, the description should explain return values (e.g., comment fields, author, likes). It does not. Also lacks context on limitations like maximum results or that it retrieves only published comments. Incomplete for a read 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 descriptions cover all 4 parameters (100% coverage), so description adds limited value. It does mention 'popular or latest' which aligns with the order parameter enum, but this is already in schema. Baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it retrieves popular or latest comments for a video, using specific verb 'retrieve' and resource 'video comments'. This distinguishes it from sibling tools like get_channel, get_video, search_videos, etc., which handle different entities.
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 explicit guidance on when to use this tool vs alternatives. The description does not mention when to prefer this over search or other retrieval tools, nor does it specify any prerequisites or use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
μ¬λ¬ λμμ ID λλ URLλ‘ YouTube λμμμ μΌκ΄ μ‘°νν©λλ€.
| Name | Required | Description | Default |
|---|---|---|---|
| videoIdsOrUrls | Yes | λμμ ID λλ 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. It states the core read operation but does not disclose any authorization needs, rate limits, or error behaviors. For a read-only tool, this is minimal but acceptable.
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?
A single, concise sentence with no wasted words. The main action is front-loaded, and every word adds value.
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 output schema and simple input, the description is adequate but could mention limits (e.g., max 50 items from schema) or return format. It is minimally complete for a basic batch lookup.
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 a description that matches the parameter. The description adds no new meaning beyond 'video ID or URL' already present in the schema. Baseline 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 (batch lookup), resource (YouTube videos), and input (multiple IDs or URLs). It distinguishes from siblings like get_video (singular) and search_videos (search).
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 does not explicitly guide when to use this tool versus alternatives. Usage is implied from context, but no exclusions or alternative suggestions are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
ν€μλλ‘ YouTube μ±λμ κ²μν©λλ€.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | κ²μ ν€μλ | |
| maxResults | No | μ΅λ κ²°κ³Ό μ | |
| order | No | μ λ ¬ κΈ°μ€ | relevance |
| regionCode | No | μ§μ μ½λ (μ: KR, US) | |
| pageToken | No | λ€μ νμ΄μ§ ν ν° |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It only states that the tool searches channels, but does not mention pagination (though pageToken parameter exists), authentication requirements, rate limits, or what data is returned. The description is insufficient for an agent to understand the tool's full 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, concise sentence. It is front-loaded with the core action. However, it could be slightly expanded to include more context without becoming verbose.
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 (5 parameters, no output schema, no annotations), the description is too minimal. It does not explain the return format, pagination, or how results are structured. The agent lacks critical information to use the tool effectively.
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%, providing descriptions for all 5 parameters. The tool description itself does not add extra meaning beyond the schema, but the schema adequately covers parameter semantics. 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 it searches YouTube channels by keyword, which is a specific verb and resource. However, it does not differentiate from the sibling tool 'search_videos', which likely searches videos instead of channels.
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_channel' or 'search_videos'. It lacks any context about appropriate usage scenarios or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
ν€μλλ‘ YouTube λμμμ κ²μν©λλ€.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | κ²μ ν€μλ | |
| maxResults | No | μ΅λ κ²°κ³Ό μ | |
| order | No | μ λ ¬ κΈ°μ€ | relevance |
| publishedAfter | No | μ΄ν κ²μλ λμμλ§ (ISO 8601, μ: 2025-01-01T00:00:00Z) | |
| publishedBefore | No | μ΄μ κ²μλ λμμλ§ (ISO 8601) | |
| regionCode | No | μ§μ μ½λ (μ: KR, US) | |
| videoDuration | No | κΈΈμ΄ νν° (short: 4λΆ λ―Έλ§, medium: 4~20λΆ, long: 20λΆ μ΄μ) | |
| pageToken | No | λ€μ νμ΄μ§ ν ν° (μ΄μ μλ΅μ pageToken) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must disclose behavioral traits. It only says 'searches YouTube videos by keyword' without mentioning rate limits, authentication needs, output format, or any side effects.
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 sentence, which is concise but lacks substantive detail to be efficient; it does not prioritize key information.
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?
With 8 parameters, no output schema, and no annotations, the description is incomplete. It fails to specify typical outputs, pagination, or filtering behavior beyond schema hints.
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% parameter description coverage, so the baseline is 3. The description does not add additional semantic meaning beyond the schema's own 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 explicitly states it searches YouTube videos by keyword, distinguishing it from sibling tools like search_channels (for channels) and get_videos (for specific videos by ID).
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, nor does it specify any prerequisites, contexts, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Each tool targets a distinct resource or action (status, channel, channel videos, playlist, playlist items, video, video comments, batch videos, search channels, search videos) with no overlaps.
All tool names follow a consistent verb_noun pattern (get_*, search_*) except api_status which is a single status check. Naming is predictable and uniform.
10 tools is perfectly scoped for YouTube data retrieval: covering channels, videos, playlists, comments, search, and status. No unnecessary tools.
The surface covers all major read operations for YouTube: channel info, channel videos, playlist info, playlist items, video details (single and batch), comments, and search for both channels and videos.
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)
Scrape YouTube videos and channels: titles, views, likes, subscriber counts, and upload dates.
Hosted MCP for YouTube Studio: uploads, metadata, playlists, comments, analytics, captions.
Search YouTube and read video, channel and transcript data as JSON. No Google Cloud project.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/iamkw0n/youtube-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server