Skip to main content
Glama
Achanandhi-M

youtube-watch-mcp

by Achanandhi-M
OverviewSchemaRelated ServersScoreDiscussions
JavaScript
Local

youtube-watch-mcp

An MCP server that tracks your favorite YouTube creators and tells you when they've posted something new — right from Claude.

You:    Add MKBHD to my YouTube watchlist
Claude: Now watching "Marques Brownlee" (UCBJycsmduvYEL83R_U4JriQ).
        Latest upload so far: "The Best Car I've Ever Driven: McLaren W1"
        — future checks will only report videos newer than this.

You:    Did any of my channels post something new?
Claude: Checked 3 channel(s), found 1 new video total.
        Marques Brownlee: 1 new video
        - "..." (2026-07-05) https://www.youtube.com/watch?v=...

No YouTube API key, no Google Cloud project, no quotas — it reads each channel's public RSS feed.

Features

  • add_channel — start tracking a creator by channel ID, @handle, or channel URL

  • remove_channel — stop tracking one

  • list_channels — see everything you're watching

  • check_new_videos — check one channel, or all of them, for uploads since the last check

  • get_latest_videos — browse any channel's recent uploads without touching tracking state

  • A watchlist://channels resource exposing your current watchlist as JSON

Related MCP server: YouTube MCP Server

How it works internally

┌─────────────┐   stdio (JSON-RPC)   ┌────────────────────┐   HTTPS   ┌──────────────────────┐
│ Claude       │ ───────────────────▶ │ youtube-watch-mcp  │ ────────▶ │ YouTube (public)     │
│ (MCP client) │ ◀─────────────────── │ (this server)      │ ◀──────── │ RSS + channel pages  │
└─────────────┘                      └────────────────────┘           └──────────────────────┘
                                              │
                                              ▼
                                     data/watchlist.json
                                     (local, persisted state)

Transport. The server communicates with its client (Claude Desktop, Claude Code, etc.) over stdio — the client spawns node dist/index.js as a subprocess and exchanges JSON-RPC messages over stdin/stdout. This is the standard local-server transport in MCP; nothing is exposed over the network.

Tools vs. resources. Each capability above (add_channel, check_new_videos, ...) is registered as an MCP tool — a function with a typed input schema (validated with zod) that the model can decide to call based on your request. watchlist://channels is registered as an MCP resource instead — a read-only piece of data a client can pull in as context without "calling" anything.

Resolving a channel with no API key (src/youtube.ts). When you pass a @handle or a channel URL, the server fetches that page's plain HTML and extracts the channel's real ID from it. This turned out to be less trivial than it sounds: a channel page's HTML contains dozens of "channelId":"UC..." strings for unrelated channels (recommended/related-channel shelves), so grabbing the first match resolves to the wrong creator. Instead, the server reads the page's <link rel="canonical"> tag and "externalId" field — both of which specifically identify the page's own owner. If you pass a raw channel ID (UC...) directly, none of this scraping happens.

Fetching uploads (src/youtube.ts). Every YouTube channel exposes a public Atom feed at:

https://www.youtube.com/feeds/videos.xml?channel_id=UC...

No auth, no quota — but it only returns the ~15 most recent uploads. The server parses this XML with fast-xml-parser into a simple { channelTitle, videos[] } shape, where videos is ordered newest-first.

Tracking "new since last time" (src/index.ts, src/storage.ts). For each watched channel, the server persists the ID of the most recent video it has seen. check_new_videos walks the freshly-fetched feed from newest to oldest and collects every video until it hits that last-seen ID (or runs out of feed, if the channel posted more than ~15 videos since the last check). It then updates the stored ID to the current newest video. add_channel seeds this "last seen" value immediately with the channel's current latest upload, so adding a channel never immediately reports its entire back-catalog as "new."

Storage (src/storage.ts). The watchlist lives in data/watchlist.json, next to the compiled server — a flat JSON array of { channelId, nickname, addedAt, lastVideoId, lastCheckedAt }. No database; it's just read, mutated, and rewritten on every change.

Setup

Prerequisites

Install & build

git clone https://github.com/Achanandhi-M/youtube-watch-mcp.git
cd youtube-watch-mcp
npm install
npm run build

This compiles TypeScript from src/ into dist/.

Connect it to Claude Code

claude mcp add youtube-watch -- node /absolute/path/to/youtube-watch-mcp/dist/index.js

Restart/reconnect Claude Code and the tools listed above become available.

Connect it to Claude Desktop

Add this to your Claude Desktop config (~/Library/Application Support/Claude/claude_desktop_config.json on macOS) under mcpServers, then restart the app:

{
  "mcpServers": {
    "youtube-watch": {
      "command": "node",
      "args": ["/absolute/path/to/youtube-watch-mcp/dist/index.js"]
    }
  }
}

Usage examples

  • "Add MKBHD and Veritasium to my YouTube watchlist"

  • "Check if any of my watched creators posted something new"

  • "Show me the last 5 videos from @fireship without adding it to my watchlist"

  • "Stop tracking Veritasium"

Limitations

  • YouTube's RSS feed only returns the ~15 most recent uploads per channel. If a channel you're tracking goes unchecked for long enough to publish more than that, older uploads in between won't be reported as "new" — check regularly rather than sporadically.

  • Channel resolution from @handle/URL scrapes public HTML rather than using an official API, so it could break if YouTube changes its page markup. Using a direct channel ID (UC...) with add_channel avoids this entirely.

  • No notifications/push — this is a pull-based tool. Nothing checks in the background; a check only happens when you (via Claude) ask for one.

Project structure

src/
  index.ts     MCP server: tool + resource definitions
  youtube.ts   Channel resolution + RSS feed fetching/parsing
  storage.ts   JSON-file watchlist persistence
data/
  watchlist.json   Your tracked channels (gitignored, created on first run)

License

MIT — see LICENSE.

Available Tools

5 tools
add_channelAdd YouTube channel to watchlistA

Start tracking a YouTube creator for new uploads. Accepts a channel ID (starts with UC), an @handle, or a full channel URL.

ParametersJSON Schema
NameRequiredDescriptionDefault
inputYesChannel ID, @handle, or YouTube channel URL
nicknameNoFriendly name to refer to this channel by later; defaults to the channel's YouTube title

TDQS

A4/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries full burden; it discloses input formats but lacks details on idempotency, side effects, or authorization needs.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, no wasted words, front-loaded key 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 tool, it covers the core action and input formats; missing edge cases like duplicate handling or success response but still adequate.

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 100% (both parameters described), but the description adds specific format details for the 'input' parameter (e.g., ID starts with UC), which goes 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 verb 'Start tracking' and the resource 'YouTube creator', and it distinguishes from siblings like 'remove_channel' and 'list_channels' by focusing on adding a channel.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage when wanting to add a channel but does not explicitly compare to siblings or provide when-not-to-use guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

check_new_videosCheck for new YouTube uploadsB

Check watched channel(s) for videos published since the last check. Omit 'channel' to check everyone on the watchlist.

ParametersJSON Schema
NameRequiredDescriptionDefault
channelNoNickname or channel ID to check; omit to check all watched channels

TDQS

B3.3/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, so description must disclose behavioral traits. It mentions 'since the last check' indicating statefulness but fails to clarify whether it is read-only, required authentication, or if repeated calls have side effects. For a tool with zero annotation coverage, this is insufficient.

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?

Single sentence of 12 words, front-loaded with purpose, no filler. Every word 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?

For a simple tool with 1 optional parameter and no output schema, the description provides essential functionality but lacks usage guidelines and behavioral transparency (e.g., statefulness implications, return format). It is adequate but not 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 coverage is 100% with a description that already covers omitting the parameter. The description adds no significant new meaning beyond the schema, so baseline 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 checks watched channels for videos published since the last check, with specific verb and resource. It also explains how to use the optional parameter to check all channels, distinguishing it from the get_latest_videos sibling which likely returns current latest without state tracking.

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 explicit guidance on when to use this tool versus alternatives like get_latest_videos. The description implies it's for incremental updates but does not compare with siblings or specify prerequisites.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_latest_videosBrowse a channel's recent uploadsA

List the most recent uploads from a channel without affecting new-video tracking. Works for any channel (watched or not).

ParametersJSON Schema
NameRequiredDescriptionDefault
limitNoHow many recent videos to show (default 5, max 15)
channelYesNickname of a watched channel, or a channel ID/@handle/URL

TDQS

A4/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description adds key behavioral context: 'without affecting new-video tracking' and 'Works for any channel'. However, it lacks details on return format, error handling, or access requirements, which would improve 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 very concise: two short sentences that are front-loaded with the main action, followed by a clarifying statement. 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?

Given the tool's simplicity (2 parameters, no output schema), the description covers the core purpose and key behavioral nuance. It could be more complete by specifying ordering or time range, but it is largely adequate.

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 schema already documents both parameters well. The description adds no extra meaning beyond the schema, resulting in a baseline score of 3.

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?

Description clearly states 'List the most recent uploads from a channel', specifying the exact action and resource. It distinguishes from sibling tools like 'check_new_videos' by noting it does not affect new-video tracking, and works for any channel.

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 this tool is for browsing recent uploads without affecting tracking, which differentiates it from 'check_new_videos'. However, it does not explicitly state when to use or avoid this tool, leaving some inference needed.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

list_channelsList watched YouTube channelsA

Show every creator currently being tracked.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

A3.7/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full burden but only states the basic purpose, omitting behavioral details like return format, data source, or any side effects.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, front-loaded sentence with no wasted words, achieving maximum conciseness.

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?

Given no output schema and no annotations, the description is adequate for a simple list tool but could benefit from specifying what information is returned (e.g., channel names or IDs).

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?

There are zero parameters, so the description cannot add meaning beyond the schema. Baseline for 0 parameters is 4, and the description is consistent.

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 'Show' and the resource 'every creator currently being tracked,' which distinguishes it from sibling tools like 'add_channel' or 'remove_channel'.

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 viewing tracked channels but provides no explicit guidance on when to use this tool versus alternatives, such as 'check_new_videos' or 'get_latest_videos'.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

remove_channelRemove YouTube channel from watchlistB

Stop tracking a creator, by nickname or channel ID.

ParametersJSON Schema
NameRequiredDescriptionDefault
channelYesNickname or channel ID to remove

TDQS

B3.4/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries full burden but only says 'Stop tracking' with no details about side effects, reversibility, or safety. Behavioral traits are minimally disclosed.

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?

Description is a single sentence of 11 words, concise and front-loaded. No wasted words, though slightly under-specified.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple one-parameter tool, the description covers the basic action and parameter format. However, it lacks information about return behavior, error states, or idempotency, leaving gaps.

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 has 100% coverage with a description for the 'channel' parameter. Tool description reaffirms the parameter's purpose but adds no new 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?

Description clearly states the tool stops tracking a creator, using a specific verb and resource. It is easily distinguishable from siblings like add_channel and list_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?

Usage is implied as the inverse of add_channel, but no explicit guidance on when to use this tool versus alternatives is provided. No exclusions or conditions mentioned.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. 5 tool updatesv1.0.0
    • First observedadd_channel
    • First observedcheck_new_videos
    • First observedget_latest_videos
    • First observedlist_channels
    • First observedremove_channel
Install Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.9/5.0
Disambiguation5/5

Each tool targets a distinct action: adding, checking, listing, and removing channels. No overlap in functionality.

Naming Consistency5/5

All tools follow snake_case verb_noun pattern (e.g., add_channel, check_new_videos), perfectly consistent.

Tool Count5/5

5 tools is appropriate for a YouTube watch tracking server, covering core operations without excess.

Completeness4/5

Covers CRUD for channels with add/list/remove, plus two video retrieval methods. Minor gap: no tool explicitly resets or updates watch status, but check_new_videos handles new video detection.

Maintenance

ActivityStale
ResponsivenessNo issues

Resources

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Related MCP Servers

  • YouTube MCP Server

    Nocodeboy
    A
    license
    Not graded
    quality
    D
    maintenance
    An MCP server that allows Claude and other AI assistants to interact with the YouTube API, providing tools to search videos/channels and retrieve detailed information about them.
    47
    1
    MIT

  • youtube-music-mcp

    dustinbarnes
    F
    license
    Not graded
    quality
    B
    maintenance
    An MCP server for managing YouTube Music playlists via Claude. Add and remove songs, create playlists, and ask Claude to suggest music — all through conversation.
    -

  • youtube-transcript-mcp

    yunlinwu
    A
    license
    A
    quality
    B
    maintenance
    An MCP server that gives Claude access to YouTube video transcripts. Extract full transcripts, search for keywords with timestamps, and get direct YouTube links to matching moments.
    2
    MIT

Latest Blog Posts

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/Achanandhi-M/youtube-watch-mcp'

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