YouTube Knowledge MCP

Server Quality Checklist

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

Latest release: v1.1.1
Disambiguation5/5
Each tool targets a distinct resource/action combination: searching vs fetching videos, retrieving metadata, transcripts, chapters, comments, channel info, playlist info, formats, downloading, and library operations. No two tools appear to do the same thing.
Naming Consistency4/5
The vast majority use a consistent verb_noun pattern (get_video_info, search_channels, list_formats). The only deviation is 'save_to_library' which uses a preposition, but it's still clear and readable.
Tool Count5/5
13 tools is well within the ideal 3-15 range and each tool serves a necessary function for the server's purpose of YouTube knowledge management—no redundancy or bloat.
Completeness4/5
The surface covers search, retrieval, metadata, transcripts, chapters, comments, channels, playlists, download, and library save/list. Minor gap: no explicit delete or update for library items, though save_to_library does overwrite.
Average 4.1/5 across 13 of 13 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 45 commits in the last 12 weeks
- Last stable release on August 14, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is failing
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

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is clear. The description adds the return fields but no additional behavioral context (e.g., whether private playlists are accessible, error behavior, or rate limits). This is adequate for a read-only operation.
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 sentence, front-loaded with the action ('Get metadata for a YouTube playlist') followed by the return fields. Every word earns its place; no filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple tool (one parameter, fully documented in schema) and robust annotations (read-only, idempotent, non-destructive), the description is complete. It clearly states the return fields, which is essential since there is no output schema. No significant gaps are apparent.
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?
Schema description coverage is 100%, and the url parameter is fully described with an example in the schema. The tool description does not add any additional parameter semantics beyond what the schema already provides, so it meets the baseline for high coverage.
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 clear, specific action: 'Get metadata for a YouTube playlist.' It lists the exact fields returned (title, channel, video count, last updated date, description), which distinguishes it from sibling tools like get_video_info and get_channel_info.
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 usage is implied by the name and description but never explicitly stated. It does not mention when to use this tool versus alternatives (e.g., for individual videos or channels), nor does it provide any exclusions or prerequisites.
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?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint, so the safety profile is covered. The description adds the returned data types (names, handles, subscriber counts) but no additional behavioral traits like pagination, rate limits, or result ordering, leaving room for more 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 short sentences, front-loaded with the action, and contains no filler or redundant info. Every word contributes to understanding the tool's purpose and output.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only search tool with a small parameter set and complete schema descriptions, the description is sufficient. It lists the return fields, compensating for the lack of an output schema, and provides enough context for an agent to select and invoke the tool correctly.
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?
Schema description coverage is 100%, with both 'query' and 'limit' fully described in the schema. The description adds little beyond the schema, only echoing 'keyword or phrase' which is already explicit in the schema. Baseline 3 applies.
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 the exact action ('Search YouTube for channels by keyword or phrase') and lists the return fields, making it clear this tool is for channel discovery, distinct from siblings like search_videos. 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for channel search but does not explicitly mention alternatives, when-not-to-use, or comparison with sibling tools such as search_videos. It provides context but lacks explicit exclusion or alternative 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?
Annotations already indicate readOnly=false, so the write nature is known. The description adds that the write is to 'local disk' and discloses the return value (file path, title, format details), which annotations do not cover. However, it does not mention other behavioral traits such as overwriting behavior or error handling, so it offers minimal but non-redundant value.
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 long and front-loads the core purpose, followed by parameter guidance and return value. No words are wasted, and it is well-structured for quick parsing by an agent.
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?
With no output schema, the description appropriately summarizes the return values. It covers the key parameter choices and gives enough context to use the tool effectively. It does not address edge cases like failures or file conflicts, but the annotations and schema fill in most missing details for a download tool.
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?
Schema coverage is 100%, with each parameter fully described. The description adds a small cross-reference between quality and formatId, but largely repeats what the schema already states. Since the schema does the heavy lifting, a baseline score of 3 is appropriate with only marginal added 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 clearly states the action ('Download') and the resource ('a YouTube video to local disk'), distinguishing it from sibling tools like get_video_info or list_formats. It also specifies the function's output (file path, title, format details), leaving no ambiguity.
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 gives explicit internal guidance on when to use quality vs formatId, and references list_formats to obtain format codes. It does not explicitly state when to use this tool versus alternatives (e.g., when only metadata is needed), but the clear purpose and parameter guidance provide adequate context.
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?
The description reveals useful behavioral details such as the returned video fields and the sort order (playlist/channel order). Annotations already cover the read-only, idempotent, and non-destructive nature, so the description adds value without needing to restate those.
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 long, front-loaded with the primary action, and includes only essential details about return values and sorting. 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 simple list tool with two parameters and no output schema, the description adequately covers purpose, return data, and ordering. It could be slightly more complete by referencing alternative tools, but overall it is sufficient.
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 schema provides complete descriptions for both parameters (url and limit), so the description does not need to add param-specific meaning. It does echo the url parameter's source types but offers no additional semantic depth.
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 'List' and a clear resource ('videos from a YouTube playlist or channel'), and specifies the return fields (IDs, titles, durations, upload dates, URLs) and ordering. This distinguishes it from sibling tools like search_videos, which focuses on keyword search.
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 the tool is for listing videos from a playlist or channel, but it does not explicitly mention when to use this tool versus search_videos or other alternatives. No exclusions or alternative guidance is provided.
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?
The description discloses important behavioral beyond annotations: it overwrites existing content of the same type for the same video, and it returns the saved file path. This adds context not covered by the idempotentHint or destructiveHint annotations, which is valuable for the agent.
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 purpose, and includes key behavioral facts without any fluff. Every sentence earns its place, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the 6-parameter schema and no output schema, the description adequately covers purpose, overwrite behavior, and return value. It does not explain the library concept or parameter relationships beyond that, but the schema fills in those details, leaving the description contextually complete for a straightforward save operation.
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?
Schema description coverage is 100%, so the baseline is 3. The description does not add significant parameter-specific meaning; 'summary or skill note' aligns with the contentType enum but does not elaborate on parameter formats or values beyond what the schema already provides.
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's function with a specific verb and resource: 'Save a summary or skill note to the local YouTube knowledge library.' It also distinguishes itself from sibling tools by focusing on writing to the library, whereas most siblings are read-oriented.
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 specify when to use this tool versus alternatives, but the context of sibling tools like list_library implies its role as the write counterpart. The overwrite note hints at usage constraints but lacks explicit exclusions or alternative tool references.
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?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is clear. The description adds the specific output fields (channel name, handle, subscriber count, description, URL), which is useful context beyond the annotations, but it does not disclose any error behavior or rate limits.
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 states the function and lists the return fields. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter read tool with strong annotations, the description sufficiently covers the purpose and output shape. The absence of an output schema is compensated by the explicit list of returned fields.
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 input schema fully describes the 'channel' parameter as a URL, handle, or name, so schema coverage is 100%. The description does not add any additional parameter semantics beyond what is in the schema.
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 'Get' and clearly identifies the resource as 'metadata for a YouTube channel', listing the exact fields returned (name, handle, subscriber count, description, URL). This distinguishes it from sibling tools like get_video_info or search_channels.
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 the tool is for retrieving metadata for a specific known channel, but it does not explicitly state when to use it over alternatives like search_channels. There are no explicit exclusions or alternative recommendations.
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?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, covering the safety profile. The description adds the specific metadata fields returned, but does not disclose error behavior, rate limits, or prerequisites. With annotations present, the extra context is useful but not extensive.
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 leads with the action and resource, followed by a clear list of return fields. Every word adds value, with no redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description carries the burden of explaining return values, which it does by enumerating all metadata fields (title, channel, duration, etc.). For a simple single-parameter, read-only tool with comprehensive annotations, this is complete.
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?
Schema description coverage is 100%, fully explaining the 'video' parameter as either an ID or full URL. The description adds no additional parameter syntax or constraints beyond the schema, so score matches the baseline for high schema coverage.
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 detailed metadata for a single YouTube video, with a specific verb and resource. It lists the return fields, which distinguishes it from siblings like get_transcript and get_comments that fetch different aspects of a 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 implies when to use the tool via 'single YouTube video', indicating it is for individual video metadata rather than search or channel-level info. However, it does not explicitly mention alternatives or exclusions, such as using fetch_videos for multiple videos.
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?
Annotations already declare read-only, open-world, idempotent, and non-destructive behavior. The description adds useful behavioral context beyond that, such as grouping by video+audio, video-only, and audio-only, which helps set expectations about the response structure.
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 verb and resource, and includes a concise list of return fields. No wasted words.
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 simple list tool with one parameter, good annotations, and no output schema, the description provides sufficient detail about return values and groupings. It lacks explicit error handling details, but that's not critical here.
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 single parameter 'video' is already fully described in the schema (ID or URL, with examples). The description does not add additional meaning beyond the schema, so the baseline score of 3 applies.
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's purpose: listing all available download formats for a YouTube video, with specific details on what is returned. It distinguishes from siblings like download_video or get_video_info by focusing on format listing.
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 usage context: when you need format IDs, resolutions, etc. for a video. It doesn't explicitly name alternatives or exclusions, but the context is clear enough for an agent to select appropriately.
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?
Annotations already indicate a read-only, idempotent, open-world operation. The description adds behavioral details beyond that: the specific output fields returned and the default relevance sort order. This gives the agent a clearer picture of what to expect, though it doesn't cover pagination or error handling.
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 three short sentences, each earning its place: the search action, the returned data fields, and the sort order. It is front-loaded with the primary purpose and contains no redundant or vague phrasing.
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 simplicity of the tool (two params, no output schema, read-only annotations), the description covers the key aspects: what it searches, what it returns, and how results are ordered. It doesn't explicitly discuss edge cases like empty results or API limitations, but the annotations and schema fill in the safety profile and parameter constraints. A small gap is the lack of alternative guidance, but that's more relevant to usage guidelines.
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 input schema has 100% coverage with descriptions for both 'query' and 'limit', so the baseline is 3. The description mentions 'keyword or phrase' which aligns with the query parameter but doesn't add additional parameter-specific detail beyond the schema. It doesn't explain the effect of the limit parameter beyond the schema's own description.
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 ('Search YouTube'), the resource ('videos'), and the method ('by keyword or phrase'). It also enumerates the returned fields (IDs, titles, durations, channels, view counts, URLs), making it distinct from sibling tools like search_channels.
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 when to use this tool: to find YouTube videos via keywords. It doesn't explicitly mention alternatives or exclusions, but the purpose is unambiguous, and sibling tool names (e.g., search_channels, get_video_info) imply the distinctions. The lack of explicit 'use this instead of...' prevents a 5.
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?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the description need not restate safety. It adds valuable behavioral context: sorting by popularity, return fields (author, text, like count, pinned status), and the limitation to top-level comments, going beyond mere annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at two sentences, with the main action front-loaded and every sentence carrying meaningful information. It avoids redundancy and unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only tool with no output schema, the description adequately covers purpose, return values, and scope limitations. Combined with strong annotations and a well-documented schema, it provides a complete picture for an agent to select and invoke the tool correctly.
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?
Schema description coverage is 100%, with both video and limit fully described in the input schema. The tool description reinforces the 'top-level comments' aspect but does not add significant meaning beyond the schema, so a baseline score of 3 is appropriate.
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 (get top comments), the resource (YouTube video), and key details (sorted by popularity, top-level only, no replies). It distinguishes itself from sibling tools like get_video_info and get_transcript by specifying its focus on comments and the exact output fields.
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 a clear scope of use (top comments, sorted by popularity) and explicitly excludes replies, guiding when not to use it. However, it does not name an alternative tool for retrieving replies or other comment types, so it falls short of the highest bar for explicit alternatives.
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?
Annotations already declare readOnlyHint=true and idempotentHint=true. The description adds valuable behavior: it returns plain text with word count and detected language, and states results are cached locally. It also notes support for both auto-generated and manual captions. These details enrich understanding beyond the annotations, though it doesn't discuss error handling or rate limits.
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 three sentences, front-loaded with the main action ('Extract the full transcript from a YouTube video') and followed by concise details on caption types, output, and caching. Every sentence contributes meaningful information, with no redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with two parameters, robust annotations, and no output schema, the description sufficiently explains the return value (plain text with word count and detected language). It also covers key behavioral aspects like caching and caption support. Combined with the schema and annotations, the tool is fully specified 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.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% with both parameters clearly documented: video accepts an ID or full URL, and language specifies ISO 639-1 code with fallback behavior and a default. The description adds no extra semantic meaning beyond the schema, so the baseline of 3 applies.
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 'Extract the full transcript from a YouTube video' with a specific verb and resource. It distinguishes itself from sibling tools like get_video_info, get_chapters, or download_video, as no other sibling retrieves transcripts. The mention of supporting both auto-generated and manual captions further clarifies its 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 usage context is clear: use this tool when you need the transcript of a YouTube video. While it doesn't explicitly name alternatives or exclusions, the tool's unique function among the siblings makes the when-to-use obvious. No misleading guidance is present.
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?
Annotations already declare read-only and idempotent, so the description adds value by disclosing return fields, sorting order, and the optional tag filter. No contradictions found.
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 main action, and includes the necessary details without any fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given one optional parameter, no output schema, and good annotations, the description fully covers what is returned, the sorting behavior, and the filter option. It is complete for this simple listing tool.
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 schema fully documents the tag parameter with a case-insensitive partial match description. The tool description merely repeats 'Optionally filter by tag' without adding new meaning, so baseline 3 applies given 100% schema coverage.
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 lists all saved items in the local YouTube knowledge library, a specific verb+resource. It also names the returned fields, distinguishing it from siblings like search_videos or get_video_info.
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 gives clear context: it is for listing saved library items, not for searching external videos. However, it does not explicitly mention alternatives or when not to use it, which would make it a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds value beyond the annotations by disclosing the return contents (titles with start/end times) and the edge case behavior (empty list if no chapters). This informs the agent about expected output and failure mode, which annotations don't cover.
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?
Three short sentences, each conveying essential information without redundancy. The description is tightly written and free of fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter read-only tool, the description is complete: it states what it returns, when it might return nothing, and the input format (covered in schema). No critical information is missing.
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 schema already thoroughly describes the 'video' parameter (ID or full URL) at 100% coverage. The description adds no additional parameter semantics, so a baseline score of 3 is appropriate.
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 opens with 'Extract chapter markers and timestamps from a YouTube video,' a specific verb+resource that clearly differentiates this tool from siblings like get_transcript or get_video_info. The additional details about chapter titles and timestamps reinforce 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: it's for extracting chapters. It implies when to use it (when you need chapter markers) but does not explicitly name alternatives or exclusion criteria. The caveat about videos without chapters adds context.
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-knowledge-mcp MCP server](https://glama.ai/mcp/servers/teobouancheau/youtube-knowledge-mcp/badges/card.svg)](https://glama.ai/mcp/servers/teobouancheau/youtube-knowledge-mcp)

Score Badge

Copy to your README.md:

[![youtube-knowledge-mcp MCP server](https://glama.ai/mcp/servers/teobouancheau/youtube-knowledge-mcp/badges/score.svg)](https://glama.ai/mcp/servers/teobouancheau/youtube-knowledge-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/teobouancheau/youtube-knowledge-mcp'

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