youtube-mcp

by EthanDM

Overview Schema Related Servers Score Discussions

TypeScript

Local

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.3.0
Disambiguation4/5
Each tool targets a distinct resource/action, but some potential confusion exists between get_owned_playlist_items and get_playlist_items, and between find_comments and get_comments. Descriptions clarify the differences, making misselection unlikely but possible.
Naming Consistency5/5
All tool names follow a consistent youtube_verb_noun pattern, using clear verbs like get, list, create, update, add, remove, reorder, search, and find. No mixing of conventions or vague names.
Tool Count4/5
With 17 tools, the set is slightly above the ideal 3-15 range, but the tools cover a broad yet focused set of YouTube features (playlists, videos, transcripts, comments). The count is reasonable for the apparent scope.
Completeness4/5
The tool set covers major lifecycle operations for playlists (create, update, add, remove, reorder) and provides video, channel, transcript, and comment retrieval. A notable gap is the lack of a delete playlist tool, which is a minor but real omission.
Average 3.5/5 across 17 of 17 tools scored. Lowest: 2.8/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 30 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It does add constraints that the video must be public and the playlist must be owned by the authenticated channel, but it omits side effects, permissions, behavior if the video already exists, and error cases. This is insufficient 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single clear sentence with no superfluous content. It is front-loaded and efficiently states the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no annotations, no output schema, and 0% schema coverage, this one-sentence description is inadequate for a 3-parameter mutation tool. It fails to clarify essential details such as parameter meanings, prerequisites, and expected behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% and the description provides no explanation of the parameters. The presence of both 'url' and 'video_url' is ambiguous, and 'position' is entirely unexplained, leaving an agent to guess which URL refers to the playlist and which to the video.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the verb 'Adds' and specifies the exact resources: a public video to a playlist owned by the authenticated channel. This clearly distinguishes it from sibling tools like youtube_remove_playlist_item and youtube_reorder_playlist_item.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. It does not mention exclusions (e.g., private videos) or point to sibling tools for removal or reordering.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the transparency burden. It discloses two behavioral traits: pagination (one explicit page) and the matchTerms scoping limitation. However, it does not mention auth requirements, rate limits, or return format, which limits transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the primary action and immediately adding a caveat. No wasted words and the critical limitation is stated efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has six parameters, no output schema, and no annotations, the description is severely incomplete. It fails to explain pagination mechanics, ordering behavior, reply inclusion, or what a returned page looks like. A much richer description is needed for an agent to use this tool confidently.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. Only matchTerms is explained further (its filtering scope), while url, limit, order, pageToken, and includeReplies remain semantically undefined. This is insufficient for a six-parameter tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves one explicit page of public YouTube comment threads, which is a specific verb-resource pair. It distinguishes from siblings by emphasizing 'one explicit page' and 'public', though it doesn't explicitly differentiate from youtube_find_comments.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no explicit guidance on when to use this tool versus alternatives like youtube_find_comments. The note about matchTerms implying a limitation is the only hint, but it doesn't direct the agent to alternate tools or state prerequisite conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that it returns 'one explicit page' of segments, indicating pagination behavior, and that segments are 'timestamped,' giving a hint about the output format. However, it does not disclose other behaviors such as authentication requirements, rate limits, or what happens when no captions are available. With no annotations, this is partial disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that front-loads the action ('Gets') and specifies the resource. No unnecessary words or repetition, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no annotations or output schema, yet the description only covers the core function and a pagination hint. It lacks details about return structure, error conditions, or how to use the language parameter. Given the complexity of 4 parameters, the description is not fully complete, but it does cover the primary purpose.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, and the description does not explain any of the four parameters (url, cursor, language, maxSegments). It implies the tool operates on a YouTube video, but does not describe how cursor, language, or maxSegments affect the call. The description adds context about the output but not about the parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves a page of timestamped YouTube caption segments, using the specific verb 'Gets' and resource 'caption segments.' It also specifies 'creator or automatic,' adding clarity. However, it does not explicitly distinguish itself from sibling tools like youtube_list_transcript_languages, though the function is clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention that youtube_list_transcript_languages lists available languages, or that this tool retrieves actual segments. No prerequisites, exclusions, or when-to-use recommendations are stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavior, but it only states the core action. It does not mention authentication requirements, read-only nature, error conditions (e.g., video has no captions), or output format.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence, using straightforward language with no redundant details. It earns its place by stating the tool's primary function without waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description provides the core purpose but lacks usage context, exclusions, and output details. For a simple single-parameter tool with no annotations or output schema, it is minimally adequate but leaves the agent to guess about response format and prerequisites.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description mentions 'for a YouTube video', which implies the url parameter is the video URL, but it does not explicitly describe the parameter or its format. Since the schema has only one required parameter, this is sufficient for basic understanding, but it adds minimal value over the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Lists' and identifies the resource as 'creator and automatic caption tracks' for a YouTube video, making the tool's purpose immediately clear. It does not explicitly contrast with sibling tool youtube_get_transcript, but the distinction (listing vs. fetching) is implicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives like youtube_get_transcript. The description only states what it does, leaving the agent to infer that listing languages should precede fetching a transcript.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does disclose that it returns a single explicit page and only public/recent uploads. However, it omits important behavioral details such as authentication requirements, ordering, rate limits, or potential error conditions, leaving significant gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one concise sentence with no filler or redundancy. It is front-loaded with the core action and resource, and every word adds meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having three parameters and no output schema, the description only provides a minimal overview. It does not explain how limit and pageToken affect results, what the response contains, or how to handle pagination—leaving the tool incomplete for an agent to invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for parameter meaning. It only clarifies that the 'url' parameter should be a YouTube channel URL, leaving 'limit' and 'pageToken' entirely unexplained. The phrase 'one explicit page' hints at pagination but does not map to the actual parameter usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('gets') and precisely identifies the resource ('one explicit page of recent public uploads from a YouTube channel URL'). It clearly distinguishes this from sibling tools like youtube_get_channel or youtube_search_videos by specifying it fetches uploads for a given channel.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, nor any exclusions or prerequisites. It does not mention that youtube_get_channel_videos is the correct choice for paginated channel uploads as opposed to search_videos or playlist tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 reveals the tool is a mutating operation ('Updates') and implies an authorization constraint, but it does not explain whether updates are partial or full, what happens if the playlist doesn't exist, or any other side effects. This is minimal transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that efficiently conveys the core purpose. Every word earns its place, with no redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 4 parameters, no annotations, and no output schema, so the description should provide more operational context. It does not mention update semantics (e.g., which fields are updated, whether missing fields are preserved), prerequisites, or error scenarios. The description is too thin for a mutating tool, though it does identify the ownership requirement.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate by explaining parameter meanings. It does not. The description only says 'metadata' without clarifying how each parameter (e.g., URL format, title constraints, privacy status) should be used, leaving semantics entirely to the schema's structural constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool updates metadata on a playlist, using a specific verb ('updates') and resource ('playlist'). The phrase 'owned by the authenticated channel' adds ownership context, and 'metadata' distinguishes it from sibling tools like add/remove playlist items, making its purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context by specifying that the playlist must be owned by the authenticated channel, implying it should be used for modifying existing playlists. However, it lacks explicit exclusions or references to alternatives (e.g., create_playlist for new playlists), so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of disclosing safety and side effects. It mentions ownership by the authenticated channel and the default private status, which adds context. However, it does not discuss authentication requirements, potential errors, or that creation is a write operation beyond the verb 'creates'.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences with no filler. It gets straight to the point and earns its length.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple create tool, the description covers core purpose and default behavior, but it lacks return value information (which is important given no output schema), error cases, and explicit guidance on when to use this tool versus siblings. It is minimally viable but has clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has three parameters (title, description, privacy_status) and schema description coverage is 0%. The description does not explain any parameter semantics, constraints, or relationships. Even the 'default to private' statement merely repeats the schema's default value, adding no new meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('Creates') with a clear resource ('a playlist') and ownership context ('owned by the authenticated channel'). It also notes the default privacy setting, which helps differentiate from update/list siblings. This is a clear and specific purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when creating a new playlist, but does not explicitly contrast with alternatives like youtube_update_playlist or mention when not to use it. No exclusions or references to sibling tools are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses a key behavior—returning only one explicit page—which is valuable for understanding pagination. Yet it omits details about error handling, response format, or authentication nuances, leaving moderate transparency gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, front-loaded with the verb 'Gets,' and contains no unnecessary wording. It efficiently conveys the core action and scope.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a paginated list tool with no annotations and no output schema, the description is minimal. It does not explain how to use pagination tokens, default limits, or what the response contains. The context provided is insufficient for an agent to fully understand the tool's behavior beyond the basic operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description fails to explain the 'limit' and 'pageToken' parameters. The phrase 'one explicit page' only vaguely alludes to pagination but does not clarify how to control page size or request subsequent pages, so the description adds no meaningful parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Gets' and clearly identifies the resource as 'playlists owned by the authenticated channel.' This distinguishes it from sibling tools that create, update, or fetch playlist items, and the phrasing 'one explicit page' adds precision about the scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context by specifying 'owned by the authenticated channel' and indicating a single-page fetch, which implies its use for reading the authenticated user's playlists. However, it does not explicitly name alternatives or state when not to use it, so it stops 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.
Behavior3/5
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 playlist must be owned and that confirmation is required, but does not mention side effects on other playlist items, error behavior, or whether the operation is reversible. This is minimally transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with two clauses, no redundant content, and is effectively front-loaded. It earns its place by stating the action and a critical requirement.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations and no output schema, the description omits essential context such as parameter semantics, error conditions, and position behavior (e.g., 0-based index, bounds checking). This makes it incomplete for correct invocation, especially for agents that cannot infer these from the schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain what 'url', 'playlist_item_id', 'position', or 'confirm' mean beyond the schema's type constraints. It leaves ambiguity about whether 'url' refers to the playlist URL or video URL, and gives no guidance on position indexing.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Moves' with a specific resource 'exact item in an owned playlist', clearly distinguishing it from sibling tools like add/remove/update. It conveys the primary function in one concise sentence.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It implies usage for reordering an item within a playlist the user owns, but does not explicitly mention when not to use it or reference alternative tools such as youtube_add_playlist_video or youtube_remove_playlist_item. The context of needing an exact item ID is helpful, but exclusions are missing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must convey behavior. It mentions 'public' which implies no authentication, and 'gets' indicates a read operation. However, it does not disclose return format, normalization details, error behavior (e.g., invalid/private URLs), or whether the video must be public. This is a significant gap for a tool with no output schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that conveys the core purpose without redundancy. Every word adds value, and it is appropriately sized for a simple getter tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no annotations, the description is too sparse to be complete. 'Normalized public metadata' is vague; it does not explain what metadata fields are returned, how normalization works, or how errors are handled. An agent cannot fully predict the tool's output or failure modes, making this insufficient for robust invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema only specifies a 'url' with format 'uri' and zero description coverage, so the tool description must clarify. The phrase 'YouTube video URL' adds meaning by specifying the URL type, which is helpful for an agent deciding what value to pass. It does not elaborate further, but for a single obvious parameter this is sufficient.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Gets') and resource ('normalized public metadata' for a YouTube video URL), clearly distinguishing it from sibling tools that fetch channels, playlists, or transcripts. It unambiguously identifies the tool's scope as single-video metadata retrieval.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not explicitly state when to use this tool versus alternatives or list exclusions, but the scope is implied: it is for obtaining metadata about a specific YouTube video. No sibling tool performs the same function, so the purpose itself gives adequate usage context, though explicit guidance is missing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral disclosure burden. It provides a valuable caveat: results only describe retrieved pages, never every comment on the video. This sets accurate expectations about partial coverage. It does not mention authentication, rate limits, or side effects, but for a read-only search tool this key limitation is well stated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no waste. It is front-loaded with the core purpose and immediately follows with the critical scope limitation. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite the useful caveat, the description is too sparse for a tool with 7 parameters, no output schema, and no annotations. It doesn't explain the meaning of order, limit, pageToken, includeReplies, or how pagination works. This leaves the agent under-informed for reliable invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for 7 parameters. It implicitly references matchTerms ('literal terms') and maxPages ('explicit bounded number of pages'), but provides no meaning for url, limit, order, pageToken, or includeReplies. This leaves significant gaps for correct parameter usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('finds literal terms') and resource ('comment pages'), with the important scope qualifier 'explicit bounded number of comment pages.' This distinguishes it from sibling tool youtube_get_comments, which presumably returns comments without term filtering.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage context is implied: use when searching for literal terms within a bounded number of comment pages. However, there is no explicit guidance on when to prefer this over youtube_get_comments or other alternatives, nor any 'when not to use' exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It says 'gets', implying a read-only operation, and mentions 'explicit item page', hinting at pagination. However, it does not disclose authentication requirements, rate limits, or what happens if the playlist is not owned, leaving behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single 14-word sentence that front-loads the verb and key qualifiers. Every word adds value, with no filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, no output schema, and zero parameter descriptions, the description is too minimal. It covers the core purpose and ownership constraint but fails to explain parameter usage, response format, or authentication nuances, making it incomplete for an agent to invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It relates 'url' to the playlist but provides no explanation of 'limit' or 'pageToken' and how they map to pagination. The phrase 'explicit item page' is a vague hint, but the parameter semantics are largely unexplained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Gets', names the resource 'playlist items', and adds key qualifiers: 'one explicit item page' and 'owned by the authenticated channel'. This clearly distinguishes it from the sibling tool youtube_get_playlist_items, which likely handles any playlist.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context by specifying the playlist must be 'owned by the authenticated channel', which signals when this tool is appropriate. However, it does not explicitly name the alternative youtube_get_playlist_items or state when not to use this tool, so exclusions are absent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the transparency burden. It discloses that the operation is a read ('Gets') and that it returns one explicit page, not all items. However, it does not mention pagination mechanics (e.g., use of pageToken), authentication requirements, or rate limits, leaving some behavioral aspects undisclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence of 15 words, front-loaded with the core action and resource. Every part adds value: 'Gets' indicates the operation, 'one explicit page' signals pagination behavior, 'public' narrows scope, and 'including item IDs and positions' clarifies key return fields. No waste or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no annotations, the description is not complete enough. It fails to explain how pagination works (despite the 'pageToken' parameter), what other fields are returned besides IDs and positions, or how to request specific pages. The tool's complexity (3 parameters) demands more context, which is absent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for missing parameter explanations. The description does not mention the 'url', 'limit', or 'pageToken' parameters at all, nor explain their purpose or relationships. It only hints at the return format (item IDs and positions), leaving parameter semantics largely to the agent's inference from names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool 'Gets one explicit page of a public YouTube playlist' with a specific verb and resource. It distinguishes from sibling tools like 'youtube_get_owned_playlist_items' by specifying 'public' and 'explicit page', and from 'youtube_list_owned_playlists' which is about listing playlists, not items.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for use: this tool is for public playlists and returns a single page. It does not explicitly mention alternatives or exclusions, but the qualifiers 'public' and 'explicit page' implicitly differentiate it from owned-playlist variants, which is enough for a clear-but-not-explicit usage guideline.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It does reveal the destructive nature ('Removes') and the confirmation requirement, but omits details about reversibility, permissions, or side effects. This is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences, front-loaded with the action, with no redundant filler or unnecessary detail. The structure is concise and effective.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a destructive mutation tool with no annotations and no output schema, yet the description gives minimal context about prerequisites, error behavior, or return values. The coverage is insufficient for safe usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It only vaguely ties 'one exact item' to playlist_item_id and 'owned playlist' to url, and restates the confirm constraint. It does not explain parameter formats, edge cases, or relationships.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Removes'), the target ('one exact item'), and the scope ('owned playlist'), distinguishing it from sibling tools like youtube_add_playlist_video or youtube_reorder_playlist_item. It is specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It specifies the prerequisite of an owned playlist and the requirement for confirm:true, providing clear context for when to use this tool. However, it does not explicitly mention alternatives or when-not-to-use it, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the burden of behavioral disclosure. It adds that only public videos are searched and that only one explicit page is returned, which is useful. But it does not mention auth requirements, rate limits, or the read-only nature beyond the verb 'searches'.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that immediately communicates the core function. It is front-loaded and contains no filler words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that there is no output schema, the description should describe the return fields of 'normalized metadata', but it does not. It also lacks details on pagination behavior and parameter semantics, making the tool under-documented.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage and the description does not elaborate on 'query', 'limit', 'order', or 'pageToken'. The schema's enum and defaults provide some meaning, but the description fails to explain how pagination or ordering works, leaving significant gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'searches' and identifies the resource as 'public YouTube videos', clearly distinguishing it from sibling tools that retrieve or list videos by ID or channel. The phrase 'one explicit page' further sharpens the scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for keyword-based search of public videos, which differentiates it from sibling tools like youtube_get_video or youtube_get_channel_videos. However, it does not explicitly state when not to use alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
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 indicates a read operation ('Gets') and references the 'local OAuth session,' but does not disclose potential errors (e.g., missing session), return format, or any side effects. For a simple getter, this is minimally adequate 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that immediately states the action and scope. Every word is purposeful, with no redundant or ambiguous phrasing. It is perfectly front-loaded and appropriately sized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (no parameters, no output schema), the description is nearly complete. It successfully conveys the core functionality, though a note about behavior when no session exists or a pointer to youtube_get_channel for non-authenticated channels would fully round out the context. Overall, it is sufficiently complete for a basic getter.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With zero parameters and schema description coverage at 100%, the baseline is 4. The description adds no parameter-specific details, but also requires none, as the input schema is empty. It appropriately avoids unnecessary elaboration.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Gets') and the specific resource ('the YouTube channel attached to the local OAuth session'). This distinguishes it from sibling tools like youtube_get_channel by specifying the authenticated context, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use this tool (when the caller needs the channel associated with the current OAuth session), but provides no explicit guidance on when not to use it or alternatives such as youtube_get_channel. Usage context is inferred rather than directly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the disclosure burden. It conveys that the operation is public and normalized, and it documents two accepted URL formats. It does not cover error behavior, return structure, or rate limits, but for a simple read-only tool the disclosed traits are valuable and accurate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single compact sentence that front-loads the action, resource, and URL format details. Every clause adds value with no filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a low-complexity tool with one parameter and no output schema, the description provides enough to select and invoke it for a public channel metadata lookup. It does not enumerate exactly which metadata fields are returned or describe failure modes, but the core purpose and input requirements are clear.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description compensates by explaining the 'url' parameter must be a YouTube channel URL and explicitly lists '/channel/...' or '/@handle' formats. This adds meaning beyond the bare 'uri' format in the schema, though it could include a concrete example.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Gets') and resource ('normalized public metadata for a YouTube channel URL'), and it names the accepted URL forms ('/channel/CHANNEL_ID' or '/@handle'). This clearly differentiates it from sibling tools like youtube_get_authenticated_channel and youtube_get_video.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies use for public channel URL lookups by specifying 'public metadata' and the URL patterns. However, it does not explicitly name alternative tools or state when not to use this tool, so it stops short of providing comprehensive usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![youtube-mcp MCP server](https://glama.ai/mcp/servers/EthanDM/youtube-mcp/badges/card.svg)](https://glama.ai/mcp/servers/EthanDM/youtube-mcp)

Score Badge

Copy to your README.md:

[![youtube-mcp MCP server](https://glama.ai/mcp/servers/EthanDM/youtube-mcp/badges/score.svg)](https://glama.ai/mcp/servers/EthanDM/youtube-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/EthanDM/youtube-mcp'

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