youtube-personal-feed

by toniher

Overview Schema Related Servers Score Discussions

TypeScript

Local

Server Quality Checklist

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

Latest release: v0.1.3
Disambiguation4/5
Each tool targets a distinct resource (subscriptions, global feed, channel uploads, playlists, liked videos, individual video), so selection is generally clear. One minor overlap is that list_liked_videos is essentially a special case of list_playlist since Liked Videos is a playlist, but the explicit dedicated tool reduces real-world confusion.
Naming Consistency4/5
Most tools follow the list_ prefix pattern and get_video is the natural singular counterpart, so the suite is predictable and readable. The mixed object types (list_feed, list_playlist, list_liked_videos) are reasonable but list_playlist doesn't explicitly state it lists videos, creating a small naming inconsistency relative to list_channel_uploads.
Tool Count5/5
Six tools is a well-scoped size for a personal YouTube feed server. Each tool serves a clear purpose without unnecessary fragmentation or bloat, covering the most common read-only data access patterns.
Completeness4/5
The server provides strong coverage of the personal feed domain: subscriptions, the main feed, channel uploads, playlists, liked videos, and single video metadata. It lacks user profile/channel info and search, but those are outside its stated purpose; the included tools form a coherent read-only extraction workflow.
Average 3.8/5 across 6 of 6 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 15 commits in the last 12 weeks
- Last stable release on August 21, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the full behavioral disclosure burden. It only states 'List videos' and reveals nothing about authentication for private playlists like 'LL', rate limits, pagination, or what the response shape looks like. This is minimal for a tool with zero annotation support.
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 definition is one concise sentence with no filler; the main action ('List videos') is front-loaded and followed immediately by the relevant scope. Every part earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with only two parameters and no output schema, and the description plus schema are enough for a basic call. However, it omits details about return shape, special playlist access requirements, or edge-case behavior, so it remains minimally viable rather than 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%, and the description adds no meaningful parameter semantics beyond what the input schema already provides. The schema itself includes the same 'LL' and 'PL...' examples for playlistId and documents maxResults, so the description is not needed for parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') and resource ('videos from any YouTube playlist ID'), with concrete examples like 'LL' and 'PL...' that clarify scope. It does not explicitly differentiate from sibling tools like list_liked_videos or list_feed, so it stops short of full sibling discrimination.
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 should be used when the agent has a YouTube playlist ID and wants the videos in it. It gives useful ID examples but provides no explicit when-to-use, when-not-to-use, or alternative tool guidance, leaving selection partially to inference.
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 disclosure burden. It usefully states that returns are standard watch URLs and references the playlist ID 'LL'. However, it does not clarify authentication expectations, pagination behavior, or explicitly frame the operation as read-only, leaving a moderate transparency gap.
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 concise, using two short sentences. The core action is front-loaded, and the return format is stated without excessive detail 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?
For a simple one-parameter list tool with no output schema, the description gives the essential operating context: the exact playlist and the URL format of the returned items. Minor missing context like auth requirements is not enough to make the definition incomplete.
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 maxResults is fully documented in the schema, including its default and bounds. The description adds nothing about the parameter, but this is acceptable since the structured schema carries the information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the verb (List), the specific resource (the user's Liked Videos playlist with the 'LL' playlist ID), and the return type (watch URLs). It does not explicitly contrast with sibling tools, but the purpose itself is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use it: when the user wants to retrieve their own liked videos. It does not mention when not to use it or point to alternatives like list_playlist or list_subscriptions, leaving some selection reasoning to the agent.
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. It discloses that the operation requires an authenticated user and returns subscription channels, but it does not describe response format, pagination behavior, or any side effects. For a simple read-only list operation, the core behavior is transparent, but additional context would be helpful.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no unnecessary words. Every element contributes directly to conveying the tool's purpose.
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 optional parameters and no output schema, the description adequately conveys the core functionality. However, it lacks details about the return value structure and any authentication scope nuances, but the complexity is low enough that the single-sentence description is nearly 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?
The input schema provides 100% coverage for both parameters (query and maxResults) with clear descriptions. The tool description does not add any meaning beyond the schema, so the baseline 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 tool's function: listing YouTube channels the authenticated user is subscribed to. The verb 'list' and specific resource 'YouTube channels the authenticated user is subscribed to' distinguish it from sibling tools like list_feed and list_channel_uploads.
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 or any exclusions. It only states the functional purpose without mentioning scenarios, prerequisites, or comparisons to sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of behavioral disclosure. It only says 'Get details' without specifying rate limits, authentication needs, quota costs, or the exact fields returned. The operation appears clearly read-only, but the minimal description does not enrich beyond the tool name.
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 directly states the tool's purpose. Every word is meaningful, with no filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
As a simple single-video fetch tool with no output schema, the description is mostly adequate. It could specify what 'details' includes (e.g., metadata, statistics), but given the simplicity and the clear contrast with list tools, it is reasonably 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?
The input schema already provides a full description of the videoId parameter, including its source ('from the watch?v= URL'). The tool description adds no extra parameter context beyond what the schema offers, 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 verb 'Get details' and the resource 'single YouTube video by ID', which distinguishes it from sibling list tools like list_subscriptions and list_feed. It precisely identifies what the tool does and 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 description implies usage when a specific video ID is known and details are needed, contrasting naturally with the sibling list tools. However, it does not explicitly state when NOT to use it or mention alternatives, so it lacks full explicit 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?
With no annotations provided, the description carries the full burden of behavioral disclosure. The verb 'List' implies a read-only operation, and 'most recent' conveys ordering. However, it does not disclose any details about authentication, error behavior, or response structure, which is a moderate gap given the lack of annotations.
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, informative sentence that is front-loaded with the action and resource. No unnecessary words or repetition, 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?
The tool is a simple list operation with only two parameters, and the description covers its core purpose and key constraint (subscription not required). While there is no output schema to explain return values, the lack of that information is acceptable for a straightforward list tool. The description is sufficient, though slightly more detail about result contents would be ideal.
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 for both parameters (channelId and maxResults), so the schema already documents semantics fully. The description adds no additional parameter-level meaning beyond what the schema provides, which aligns with the baseline score of 3 for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
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: listing the most recent uploads of a specific channel. It includes a scope qualifier ('not required to be subscribed') that distinguishes it from sibling tools like list_subscriptions and list_feed, which focus on subscriptions or the user's feed.
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: for any channel's uploads, regardless of subscription status. However, it does not explicitly mention alternatives or when not to use it, so it falls short of a full 'when/when-not' guideline.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It discloses the output format (standard YouTube watch URLs) and the default scope (all subscribed channels), which is useful. However, it doesn't mention auth requirements, ordering guarantees, pagination, or potential errors, leaving a moderate transparency gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences, front-loaded with purpose, then output format. Every phrase earns its place, and there is no redundant content 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?
For a simple optional-parameter list tool with no output schema, the description provides the essential return format and scope, plus a hint about downstream use. It could mention ordering/pagination, but 'most recent' implies ordering and the URL output is the key return detail. This is slightly above minimum viable.
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 covers all three parameters (limit, channelId, sinceDays) with descriptions at 100% coverage. The description adds no additional parameter semantics beyond saying the feed is 'across all subscribed channels,' which overlaps with the schema. Baseline 3 is appropriate since the schema does the heavy lifting.
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') with a clear resource scope ('most recent uploads across all subscribed channels') and clarifies it's the subscription feed. This strongly distinguishes it from sibling tools like list_channel_uploads (single channel) and list_subscriptions (list of 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 phrase 'across all subscribed channels' and 'subscription feed' establishes when this tool is appropriate versus a single-channel listing tool. It doesn't explicitly name alternatives or state exclusions, but the context is clear enough for an agent to decide between list_feed and list_channel_uploads.
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-personal-feed MCP server](https://glama.ai/mcp/servers/toniher/youtube-personal-feed/badges/card.svg)](https://glama.ai/mcp/servers/toniher/youtube-personal-feed)

Score Badge

Copy to your README.md:

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

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/toniher/youtube-personal-feed'

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