YouTube MCP Server

by DivyaV18

Overview Schema Related Servers Score Discussions

Python

Local

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation5/5
All tools target distinct resources and actions. Channel stats, activities, videos, playlists, subscriptions, captions, search, upload, and update are clearly separated with no overlapping purposes.
Naming Consistency4/5
Most tools follow a consistent verb_noun snake_case pattern (get_channel_statistics, list_channel_videos, update_video). One outlier is 'video_details' which is a noun phrase rather than verb-first, but it's readable and doesn't cause confusion.
Tool Count5/5
14 tools is well within the ideal range and matches the broad YouTube API scope. Each tool covers a significant operation, and no redundant tools are present.
Completeness3/5
The set covers read operations comprehensively (search, details, lists) and includes upload/update for videos. However, missing delete operations (videos, playlists, subscriptions, captions) and playlist creation/modification are notable gaps that limit full lifecycle management.
Average 4.3/5 across 14 of 14 tools scored. Lowest: 3.6/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
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?
With no annotations, the description must disclose behavioral traits like read-only nature, authentication needs, rate limits, or side effects. It only mentions the return structure, which is redundant given an output schema exists, and does not explicitly state that the operation is safe or requires specific permissions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with Args and Returns sections, but the Returns section is redundant given the output schema. It is still reasonably concise and every additional detail (like default 'part' value) adds value, but could be trimmed slightly by omitting the output structure.
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?
The tool is simple with 2 parameters and an output schema. The description covers the core functionality and parameter details adequately. However, it omits any context about authentication or rate limits, which might be relevant for a YouTube API, but given the read-only nature, this is a minor gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Despite 0% schema description coverage, the description thoroughly explains both parameters. It gives the format for 'id' (comma-separated, starts with 'UC') and detailed guidance for 'part', including default values and usage examples. This fully compensates for the schema's lack of descriptions.
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 statistics for YouTube channels including subscriber counts, view counts, and video counts.' This specifies a verb, resource, and outcome, and it is distinguishable from siblings like get_channel_activities.
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 such as get_channel_activities or get_channel_id_by_handle. The description only states what it does without any contextual usage cues or 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 for behavioral disclosure. It mentions the mutation (subscribe), auth context ('authenticated user'), and input validity ('must be valid and existing'). However, it does not disclose idempotency (duplicate subscriptions), required OAuth scopes, rate limits, or side effects, leaving notable gaps for a write operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is structured with clear sections (description, Args, Returns) and remains concise. It front-loads the core purpose and then adds parameter/return details. Minor redundancy ('must be valid and existing' adds little) but its length is appropriate for the content.
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 single-parameter subscription tool, the description covers the purpose, the parameter, and the return shape. It lacks edge-case behaviors (duplicate subscriptions, permission errors) but the output schema (if present) is not shown, and the description itself provides sufficient context for straightforward invocation. The mention of 'authenticated user' sets expectations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% (only a raw string field), and the description compensates effectively by explaining channel_id as a 'Unique identifier (ID) of the YouTube channel to subscribe to (typically starts with 'UC')'. This adds meaningful semantic detail beyond the schema, including a useful format hint.
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+resource construction ('Subscribes the authenticated user to a specified YouTube channel') and clearly differentiates from siblings like list_user_subscriptions (listing vs. subscribing) and search_youtube (finding vs. subscribing). It also specifies the exact identifier type (channelId).
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 such as list_user_subscriptions or get_channel_id_by_handle. It implies usage ('subscribe to a channel') but does not state prerequisites beyond having a valid channel ID, which is a constraint rather than usage direction.
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 does disclose input flexibility ('May include or omit the '@' symbol') and return structure (data, error, successful). However, it does not explicitly state that this is a read-only operation, nor does it detail failure modes or authentication requirements beyond a generic error field.
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 concise docstring with Args and Returns sections. It is front-loaded with the purpose statement, uses clear structure, and contains no unnecessary verbiage.
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 one-parameter tool, the description provides essential context: input format and return shape. It could be more explicit about behavior for invalid handles, but the generic error field covers this. Overall, it is complete enough for the tool's complexity.
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 coverage is 0% – the schema only specifies type 'string'. The description compensates by explaining that the parameter is a YouTube handle, providing an example ('@Google'), and noting the '@' symbol is optional. This adds significant meaning beyond 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 clearly states 'Retrieves the YouTube channel ID for a specific YouTube channel handle' – a specific verb and resource. This distinguishes it from sibling tools like search_youtube or list_channel_videos, which serve different purposes.
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: provide a channel handle to get its ID. However, there is no explicit guidance on when to use this tool over alternatives (e.g., search_youtube) or when not to use it. The Args section explains the input requirement but does not provide decision criteria.
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 full burden for behavioral disclosure. It does reveal important traits: results are filtered to type 'video', pagination uses page_token with nextPageToken, max_results has defaults, and returns an object with data/error/successful. However, it omits details like authentication requirements or quota effects, so transparency is moderate.
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 well-structured and concise, beginning with a clear summary sentence followed by an Args section and a Returns section. Every sentence adds value, and there is no redundancy or filler.
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?
The description covers the core behavior, parameter semantics, and return format, which is sufficient for a relatively simple listing tool. Since an output schema exists, the description does not need to detail the data field. It could optionally mention error scenarios, but the current coverage is nearly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/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 fully compensate. It does so effectively by explaining each parameter: channel_id as the unique channel identifier, max_results with default (5) and maximum (50), page_token for pagination referencing nextPageToken, and part with a required value of 'snippet'. This adds substantial meaning beyond the bare 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 clearly states the tool's function: 'Lists videos from a specified YouTube channel, ensuring results are of type video.' The added constraint of filtering to video type distinguishes it from sibling tools like search_youtube or get_channel_activities, making the purpose 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 provides clear context that this tool retrieves channel-specific videos, but it does not explicitly state when to prefer this over siblings such as search_youtube or get_channel_activities. No exclusions or alternative recommendations are given, so the usage guidance is implied rather than explicit.
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. It discloses supported formats, argument semantics, and the return shape, plus privacy values. However, it does not mention authentication requirements, quota costs, upload processing behavior, or potential side effects like immediate publication.
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 well-structured with Args and Returns sections, remains compact, and every sentence adds useful information. 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?
Given the presence of an output schema and a moderate parameter count, the description covers invocation essentials comprehensively. It could add guidance on prerequisites or quota impact, but is largely complete for selecting and invoking the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description explicitly defines every parameter, provides an example for category_id ('22' for People & Blogs), and enumerates valid privacy_status values. This adds significant meaning beyond the raw schema field 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 opens with a specific action verb ('Uploads a video') and clearly specifies the source ('local file path') and destination ('YouTube channel'). This distinguishes it from sibling tools like update_video or update_thumbnail.
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 purpose is clearly implied as the tool for uploading new videos, but there is no explicit guidance on when to use this versus alternatives (e.g., update_video for editing existing videos) or exclusions. Context is present but not elaborated.
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 states the auth requirement and the return shape (data, error, successful), providing more transparency than many mutation tools. However, it does not mention whether the change is reversible, how it affects existing thumbnails, or any rate limits. This is moderate but not exhaustive.
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 well-structured with a clear first line stating the action, followed by permission, then parameter details, and return info. Every sentence adds necessary information without redundancy or fluff. It is appropriately sized for a simple tool with two parameters.
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 low complexity and minimal parameter count, the description covers the key aspects: prerequisites, parameter specifications, and return format. The output schema exists, so not explaining every return field is acceptable. Minor gaps like error handling or impact on existing thumbnails prevent a perfect score, but the description is complete enough for confident use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has no parameter descriptions (0% coverage), so the description must compensate. It thoroughly explains both parameters: thumbnail_url includes format, size, and dimension constraints; video_id is clearly identified. This fully adds meaning beyond the raw schema and effectively guides 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 tool's verb and resource: 'Sets the custom thumbnail for a YouTube video using an image from thumbnailUrl.' It specifies the exact action and target, distinguishing it from siblings like update_video and upload_video. The purpose is unambiguous and specific.
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 a clear context for use: updating a video thumbnail, with the prerequisite that the user must have permission to edit the video. Although it does not explicitly mention alternatives or exclusions, the context is strong enough to know when to apply this tool. No sibling comparisons are made, but the action is self-contained.
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 full burden. It discloses the return format (object with data, error, successful), the default part list, and lists valid parts. This provides meaningful behavioral context beyond a bare 'retrieves details.' It does not mention authentication or rate limits, but the error-handling and defaults are 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 well-structured and front-loaded with the purpose statement. The Args and Returns sections are clear and concise, with no redundant or filler content. Every sentence provides necessary information.
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 retrieval tool, the description is complete: it covers parameter semantics, defaults, valid parts, and return structure. It lacks explicit mention of API key or OAuth requirements, but given the output schema exists and the tool is straightforward, this is acceptable. Minor gaps exist in not addressing error scenarios in detail.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description thoroughly explains both parameters: id (YouTube video ID, typically 11 characters) and part (comma-separated list with valid values and default). This adds substantial meaning over the bare schema, making the tool usable without consulting external docs.
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 'Retrieves specified information parts... for a YouTube video, identified by its id,' which clearly states the verb (retrieve), the resource (YouTube video details), and the unique identifier (id). This distinguishes it from sibling tools like search_youtube or get_channel_statistics, which serve different purposes.
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: call it when you have a YouTube video ID and need specific resource parts. However, it does not explicitly mention when to prefer this over alternatives, such as search_youtube, or provide exclusions. There is no clear 'when not to use' guidance, so it remains at the implied level.
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 full burden of behavioral disclosure. It explains failure on invalid video ID, returns empty list when no captions exist, and details the return object structure. This is strong transparency, though it omits any mention of authentication, pagination, or permission requirements.
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 well-structured: opening summary, then Args section, then Returns section. It is concise, front-loaded with the key purpose, and every sentence adds value without unnecessary verbosity.
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 list operation with two parameters, the description is complete. It covers edge cases (empty list, invalid ID), parameter details, and return format. The presence of an output schema does not create gaps since the description already explains the return object.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no descriptions for parameters (0% coverage), but the description fully compensates. It defines 'video_id' clearly and for 'part' explains it is comma-separated, lists valid parts, and states the default. This adds significant meaning beyond 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 clearly states the tool's function: retrieving a list of caption tracks for a YouTube video. The verb 'Retrieves' and resource 'caption tracks for a YouTube video' are specific, and the tool is distinct from sibling 'download_caption_track' which downloads rather than lists.
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 by explaining parameters and return behavior, but it does not explicitly state when to use this tool over alternatives such as download_caption_track. It lacks explicit 'when to use' or 'when not to use' guidance, so use is only implied.
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 full burden and discloses the ownership requirement, the return content as text, and the exact return object shape (data, error, successful). It does not mention potential errors or rate limits, but for a simple download operation, it provides solid 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 uses a clean Args/Returns structure, with every sentence providing useful information and no redundancy. It is appropriately sized for the tool's complexity.
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 two-parameter tool with an output schema, the description covers all necessary context: what it does, ownership requirement, parameter details, and return format. It is complete 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.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, and the description fully compensates by detailing each parameter: id's origin from list_captions and tfmt's allowed formats and default. This adds significant meaning beyond the bare schema properties.
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 downloads a specific YouTube caption track owned by the authenticated user, with a specific verb ('downloads') and resource. It distinguishes itself from siblings like list_captions by focusing on the download action.
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 appropriate usage context by noting the id comes from list_captions response, indicating a dependency. It does not explicitly name alternatives or exclusions, but the context is clear enough for an agent to infer when to use this tool.
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?
No annotations are provided, so the description carries the transparency burden. It discloses the output format ('Object with data, error, successful boolean'), pagination behavior, and filter options. It does not mention authentication requirements or rate limits, but the 'get' verb implies 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 well-structured with a concise one-sentence summary, a clear Args list covering all six parameters, and a Returns section. It is appropriately sized for a tool with six parameters, with no unnecessary verbosity.
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 tool's complexity (six parameters) and the presence of an output schema, the description is complete: it explains all parameters, their constraints, and the return shape. It fully compensates for the lack of schema descriptions and provides sufficient context for an agent to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero field descriptions, so the description must compensate. It does so comprehensively: channel_id format (starts with 'UC'), max_results range (0-50), page_token purpose, part examples ('snippet', 'contentDetails', 'id'), and date formats (RFC 3339). This far exceeds the schema's bare titles and types.
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 begins with a specific verb and resource: 'Gets recent activities from a YouTube channel including video uploads, playlist additions, likes, and other channel events.' This clearly distinguishes it from sibling tools like list_channel_videos (videos only) and get_channel_statistics (statistics).
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 the tool (when recent channel activities are needed) and gives examples of activity types. However, it does not explicitly name alternative tools or state when not to use it, so it lacks exclusions but is not misleading.
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?
Despite no annotations, the description discloses the return shape (data/error/successful), the implicit mine=true behavior, and parameter defaults. It doesn't mention authentication requirements or rate limits, but it covers the key behavioral traits.
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 well-organized with a one-line summary, an Args list, and a Returns section. Each sentence provides necessary information without waste.
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?
All necessary details for invoking the tool are present: purpose, scope, parameter semantics, and return value structure. Simple read operation with no side effects, so no additional behavioral caveats are needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% (parameter descriptions are absent), and the description fully compensates by explaining max_results range/default, page_token purpose, and part accepted values/default. This adds significant meaning beyond 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 clearly states the action ('Retrieves playlists owned by the authenticated user') with a specific resource and scope. This differentiates it from sibling tools like list_user_subscriptions or get_channel_activities.
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 the authenticated user's own playlists via 'implicitly using mine=true', but does not explicitly name alternative tools or when-not to use. Provides clear context, no exclusions.
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 full burden of disclosing behavior. It clearly states retrieval (read-only) and explains pagination via max_results and page_token, and part selection, which are behavioral traits. It does not detail authentication scopes or quota limits, but the 'authenticated user' phrase implies auth requirements. This is more transparent than a minimal description.
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 well-structured with a clear purpose statement, an Args section listing each parameter with defaults and valid options, and a Returns section. Every sentence earns its place; it is concise yet complete, covering all necessary information without 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?
The description fully specifies the tool's function, parameters, defaults, and return format. Since an output schema exists, it need not detail return fields beyond the summary provided ('data', 'error', 'successful'). For a list operation of this complexity, the description is complete and self-sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides only types and defaults with zero description coverage. The description compensates thoroughly by explaining each parameter: max_results (range 0-50, default 5), page_token (from previous response), and part (valid values and default). This adds substantial meaning beyond the raw 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 clearly states the tool's action and target: 'Retrieves the authenticated user's YouTube channel subscriptions.' This specific verb+resource combination distinguishes it from sibling tools such as list_user_playlists or list_channel_videos, leaving no ambiguity about its function.
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 is for retrieving the authenticated user's subscriptions with optional pagination and part selection. It does not explicitly mention when to avoid using it or provide alternative tool references, but the intended use case is evident. This aligns with 'clear context, no exclusions'.
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 takes on the full burden. It discloses that the tool returns the raw API response and provides a structured result object with data/error/successful. It also explains pagination via page_token and max_results, though it doesn't mention rate limits or authentication requirements.
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 well-organized with an overview sentence, an Args section, and a Returns section. Every line adds value—parameter details are precise and the return contract is stated. No filler or redundant content.
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 tool's complexity (five parameters, rich query syntax, multiple resource types), the description covers all essential aspects: purpose, query syntax, parameters, pagination, and return format. An output schema exists for the return value, so the explanation of the response object is sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, so the description fully compensates. Every parameter is elaborated: 'q' includes query syntax examples, 'max_results' states range and default, 'page_token' explains pagination, 'part' defines acceptable values, and 'type' lists supported resource types.
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 begins with a specific verb 'Searches', names the resource 'YouTube', and defines the scope as 'videos, channels, or playlists'. This clearly distinguishes it from the sibling tools, which target narrower actions like channel statistics or video uploads.
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 the tool: any search across YouTube content types. It details supported query syntax and result narrowing via the 'type' parameter, but does not explicitly name alternative tools or exclusions, so it earns a 4 rather than 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?
With no annotations provided, the description carries the full burden. It discloses important behaviors: tag replacement semantics ('An empty list for tags removes all existing tags'), partial update behavior ('Omitted fields are left unchanged'), and the requirement that the video exists. It could add permission or error details, but the disclosed behaviors are material and well-covered.
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 well-structured with a brief opening statement, a clear args list with per-parameter explanations, and a return format summary. Every sentence adds necessary information, with no fluff or redundancy. The length is appropriate for the six-parameter tool.
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?
All six parameters are documented, the return object is described, and key behavioral nuances (e.g., empty tags removal, omitted fields unchanged) are covered. The presence of an output schema reduces the need to detail return structure, but the description still provides it. This is complete for effective tool usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description is the sole source of parameter meaning. It explains each parameter in detail: video_id, title, description, tags (including empty list behavior), category_id, and privacy_status (with allowed values). This exceeds the schema's minimal type information and adds crucial 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 clearly states the tool's function: 'Updates metadata for a YouTube video identified by videoId'. This specific verb-resource pairing distinguishes it from siblings like upload_video or update_thumbnail. It also emphasizes that the video must already exist, which is a clear 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 is for updating existing video metadata, and it states prerequisites ('video must exist') and semantic rules ('Omitted fields are left unchanged'). It does not explicitly name sibling alternatives or state when not to use it, but the context is sufficient for most cases.
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/DivyaV18/Youtube-mcp/badges/card.svg)](https://glama.ai/mcp/servers/DivyaV18/Youtube-mcp)

Score Badge

Copy to your README.md:

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

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