yt-outlier-mcp
This server helps you identify viral YouTube videos on small channels where the format (not the audience) drove the views, enabling you to replicate those formats.
find_outliers: Search YouTube by topic phrase to surface videos on small channels (≤100K subs) that massively outperform both their subscriber base (≥5:1 views:subs ratio) and the channel's own typical upload performance — proving the format is algorithmically replicable.get_video_structure: Given a video ID or URL, extract its replicable format elements: duration, tags, chapters (parsed from description timestamps), full description, and transcript — so you can copy the structure, not just the topic.get_comment_signal: Fetch top comments from a video and get demand metrics (question-asking comments, "please make more"/"part 2" phrasing) to verify the topic has genuine unmet audience demand.search_niche_sweep: Run the outlier search across up to 8 niches simultaneously using a phrase template (e.g. "beginner mistakes {niche}") and rank all hits by views:subs ratio — identifying which niche currently has the most replicable breakout format.get_channel_baseline: Starting from a channel (by ID, @handle, or URL), compute its median recent-upload view baseline and flag which of its recent uploads are outliers — useful when you already have a specific channel to investigate.
Provides tools to find outlier YouTube videos on small channels, extract video structure and transcripts, and analyze comments for demand signals.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type
@followed by the MCP server name and your instructions, e.g., "@yt-outlier-mcpfind outliers for 'beginner mistakes sourdough'"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
yt-outlier-mcp
MCP server that finds YouTube outlier videos: videos on small channels (≤100K subs) with one video massively outperforming both the channel's subscriber base (≥5:1 views:subs) and the channel's own recent uploads. That signature means the recommendation algorithm rewarded the format, not an existing audience — so the format is replicable by a new channel.
The method is the "Icon Method" qualifying criteria proven manually on
@Before-You-Start (see hobby-channel/IDEAS.md); this server automates it as
one MCP tool. Origin: idea #2 in _ideas/next-batch.html (paid MCP servers).
Tool: find_outliers
Input | Default | Meaning |
| (required) | Topic phrase, e.g. |
| 100,000 | Max channel subscribers |
| 100,000 | Min video views |
| 5 | Min views:subs ratio |
| 365 | Freshness window (older outliers are stale evidence) |
| 3 | Video views vs. median of channel's other recent uploads |
| 0 (off) | Min fraction of query terms found in title/description/tags; |
| 10 | Cap on returned outliers |
Pipeline per call: search.list (order=viewCount, the expensive call) →
batch videos.list + channels.list → cheap-filter by views/subs/ratio →
for survivors, pull the uploads playlist and compare against the channel's
median recent-upload views (the outlier-vs-baseline check that separates a
breakout format from a big channel's normal video).
Output per outlier: URL, views, subs, ratio, channel median views,
outlier factor, queryRelevance (fraction of query terms found in
title/description/tags — always reported, filtered only if
minQueryRelevance > 0; costs zero extra quota since the snippet is already
fetched), comments-enabled flag (comments are the manual demand-signal
step), channel video count, plus total quota units consumed.
Related MCP server: youtube-research-mcp
Tool: get_video_structure
Icon Method verification step 2 — extract the replicable format instead of
guessing it. Takes a video ID or URL; returns duration, tags, chapters
(parsed from 0:00 Intro-style description lines), the description, and the
transcript. Costs 1 quota unit; the transcript itself is fetched outside
the Data API at zero quota (captions.download needs owner OAuth, so the
server asks the InnerTube player endpoint as the ANDROID client — unofficial,
returns transcript: null gracefully if YouTube ever gates it).
Input | Default | Meaning |
| (required) | Video ID or URL (watch/shorts/youtu.be forms) |
| true | Fetch the transcript |
| 15,000 | Truncation cap |
Tool: get_comment_signal
Icon Method verification step 3 — comments prove unmet demand, not just views. Returns the top relevance-ordered comments (author, text, likes, replies) plus quick counts: comments asking questions and comments using demand phrasing ("please make…", "part 2", "how do you…"). Handles comments-disabled videos gracefully. Costs 1 quota unit.
Input | Default | Meaning |
| (required) | Video ID or URL |
| 30 | Top comments to fetch (max 100) |
Tool: search_niche_sweep
Runs find_outliers once per niche by substituting each niche into a phrase
template, then ranks every hit across all niches by views:subs ratio — the
niche that keeps appearing up top is where the replicable format lives.
Expensive: each niche is a full search (~110–130 units), max 8 niches per
sweep. Per-niche API errors are recorded without killing the sweep; a
quota-exhausted error aborts the remaining niches with a note.
Input | Default | Meaning |
| (required) | Phrase containing |
| (required) | 1–8 niches to substitute |
| 5 | Cap per niche |
filters | same as |
|
Tool: get_channel_baseline
The inverse entry point: you already have a suspect channel (from a
competitor, a comment, another tool) instead of a topic query. Computes the
channel's baseline — median views of its recent uploads — and scores every
recent upload against it, flagging outliers. Cheap: ~3 quota units (no
search.list call). Accepts channel ID, @handle, or channel URL.
Input | Default | Meaning |
| (required) | Channel ID ( |
| 15 | Recent uploads to fetch for the baseline (3–50) |
| 3 | Flag uploads at ≥ this multiple of the channel median |
Setup
npm install
npm run buildConfigure in a client (Claude Code example):
claude mcp add yt-outliers -e YOUTUBE_API_KEY=<key> -- node <abs-path>/dist/index.jsBYO key: needs a YouTube Data API v3 key (.env.example). Free quota is
10,000 units/day; one find_outliers call costs ~110–130 units (search=100,
everything else 1/call), so ~75–90 searches/day. The BYO-key model is what
makes this sellable without a Google quota-extension audit.
Roadmap
Live-test tool against real niches (2026-07-10: 4 real outliers on "beginner mistakes sourdough", 110 units/call as predicted)
Phase 2 tools:
get_video_structure(chapters/transcript) andget_comment_signal(top comments → demand resonance) to automate Icon Method verification steps 2–3 (2026-07-10, live-tested)search_niche_sweep: rotate one phrase template across hobby clusters (2026-07-10, live-tested: 2-niche sweep = 210 units, cross-niche ranking works)List on Smithery (2026-07-10): live at smithery.ai/servers/phillipmex3/yt-outlier-mcp. MCPize deferred (their SDK/hosting required; actual rev share 80%, not the 85% marketed) — revisit if Smithery shows install signal.
Publishing note
Smithery's registry requires each tools[] entry in manifest.json to carry an
inputSchema, but npx @anthropic-ai/mcpb pack rejects that key as invalid.
Workaround used here: pack the bundle from a manifest without the schemas,
then replace manifest.json inside the .mcpb (it's a plain zip) with the
schema-bearing version in this repo before smithery mcp publish.
Available Tools
4 toolsfind_outliersFind YouTube outlier videosA
Search YouTube for a topic phrase and return videos on small channels that hugely outperform the channel's subscriber base and its own recent uploads — evidence the FORMAT drove the views (replicable by a new channel), not an existing audience. Defaults encode the Icon Method criteria: ≥100K views, channel ≤100K subs, ≥5:1 views:subs, uploaded within the last year. Costs ~110-130 YouTube API quota units per call (free daily quota: 10,000).
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Topic search phrase, e.g. "beginner mistakes sourdough" or "how to win backgammon" | |
| maxSubs | No | Maximum channel subscriber count | |
| minRatio | No | Minimum views-to-subscribers ratio | |
| minViews | No | Minimum video view count | |
| maxResults | No | Maximum outliers to return | |
| minOutlierFactor | No | Video views must be at least this multiple of the channel's median recent-upload views | |
| publishedWithinDays | No | Only consider videos uploaded within this many days |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full behavioral disclosure. It reveals the tool's cost (~110-130 API units), the logic behind defaults, and that it searches by topic. It does not mention output format or auth requirements, but provides sufficient transparency for typical agent use.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences long, each with a distinct purpose: purpose + logic, defaults, and cost. It is front-loaded with the most critical information and contains no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description explains the tool's purpose and usage well, but lacks details about the output format (e.g., fields returned) and potential pagination or sorting. Given the complexity and no output schema, this is a minor gap but still leaves the agent partially uninformed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so each parameter is already documented. The description adds little beyond the schema beyond explaining the overall logic and default values (Icon Method). This meets the baseline but does not substantially enrich parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: search YouTube for outlier videos on small channels that outperform expectations. It uses specific verbs ('Search') and resources ('YouTube videos'), and the logic of format-driven vs. audience-driven success distinguishes it from sibling tools like get_comment_signal or get_video_structure.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when to use the tool (to find replicable format-driven outliers) and provides clear context (Icon Method criteria). However, it does not explicitly state when not to use it or compare with sibling tools, leaving the agent to infer from context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_comment_signalRead a video's comment demand signalA
Fetch a video's top comments (relevance-ordered) plus simple demand metrics: how many ask questions and how many use demand phrasing ('please make...', 'part 2', 'how do you...'). Icon Method verification step: comments prove the topic has unmet demand, not just views. Costs 1 YouTube API quota unit.
| Name | Required | Description | Default |
|---|---|---|---|
| video | Yes | YouTube video ID or URL (watch/shorts/youtu.be forms) | |
| maxComments | No | Number of top comments to fetch |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses that comments are relevance-ordered, metrics are simple (questions and demand phrasing), and costs 1 quota unit. It does not explicitly state whether the tool is read-only or any authentication needs, but these are implied.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences plus a cost note, highly concise and front-loaded. Every sentence adds value: purpose, use case, and cost.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 2 parameters, no output schema, and no annotations, the description explains the tool's output (top comments and demand metrics) and purpose (verification step). It could describe the return structure more explicitly but is adequate for selection.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds minimal new meaning beyond the schema: it repeats that 'video' can be ID or URL and mentions default values for maxComments. No additional semantic depth.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Fetch' and the resource 'video's top comments plus simple demand metrics'. It distinguishes itself from sibling tools like find_outliers, get_video_structure, and search_niche_sweep by focusing on comment-based demand signal.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a specific use case: 'Icon Method verification step: comments prove the topic has unmet demand, not just views.' It also notes the cost in API quota. However, it does not explicitly state when not to use this tool or mention alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_video_structureGet a video's replicable structureA
Fetch what makes an outlier video's format copyable: duration, chapters (parsed from the description), tags, and the transcript. Icon Method verification step: extract the structure, don't guess it. Costs 1 YouTube API quota unit (transcript is fetched outside the API at zero quota and may be unavailable for some videos).
| Name | Required | Description | Default |
|---|---|---|---|
| video | Yes | YouTube video ID or URL (watch/shorts/youtu.be forms) | |
| includeTranscript | No | Fetch the transcript (slower; adds no quota cost) | |
| maxTranscriptChars | No | Truncate the transcript to this many characters |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description effectively discloses cost (1 YouTube API quota unit), transcript fetching details (outside API, zero quota, may be unavailable), and potential slowness. However, it does not mention error handling, rate limits, or response format beyond listing returned fields.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, consisting of two sentences that front-load the purpose and then add critical cost/availability context. Every sentence is meaningful with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of an output schema and three optional parameters, the description adequately outlines the returned fields (duration, chapters, tags, transcript) and key constraints. It could be more explicit about the response structure, but the current text is sufficient for agent understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers 100% of parameters with descriptions, so the tool description adds minimal value for parameters. It does not elaborate on the video input format or the effects of includeTranscript/maxTranscriptChars, but the schema provides adequate defaults and types. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool fetches a video's structure (duration, chapters, tags, transcript) for replication. It's specific to outlier videos and the 'Icon Method,' but the jargon may confuse some agents. It distinguishes from sibling tools like find_outliers or get_comment_signal by focusing on structure.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description lacks explicit guidance on when to use this tool versus alternatives. It mentions 'Icon Method verification step' but does not explain when not to use it or provide comparisons with siblings like find_outliers or search_niche_sweep.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_niche_sweepSweep a phrase template across nichesA
Run the outlier search once per niche by substituting each niche into a phrase template (e.g. "beginner mistakes {niche}" across ['sourdough', 'bonsai', 'leathercraft']) and rank the hits across all niches. Answers: which hobby cluster has a replicable breakout format right now? EXPENSIVE: each niche costs a full search (~110-130 quota units), so an 8-niche sweep uses ~10% of the 10,000-unit daily free quota.
| Name | Required | Description | Default |
|---|---|---|---|
| niches | Yes | Niches to substitute into the template (max 8 per sweep to cap quota) | |
| maxSubs | No | Maximum channel subscriber count | |
| minRatio | No | Minimum views-to-subscribers ratio | |
| minViews | No | Minimum video view count | |
| template | Yes | Search phrase template containing "{niche}", e.g. "beginner mistakes {niche}" | |
| minOutlierFactor | No | Video views must be at least this multiple of the channel's median recent-upload views | |
| maxResultsPerNiche | No | Maximum outliers to return per niche | |
| publishedWithinDays | No | Only consider videos uploaded within this many days |
TDQS
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 explains the mechanism (substituting niche into template, running outlier search per niche) and discloses the expensive nature. However, it does not mention if the tool is read-only or any side effects, and output format is unspecified.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two clear paragraphs: one for purpose and one for cost. It front-loads the action but could be slightly more structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 8 parameters and no output schema, the description omits what the returned data looks like. It says 'rank the hits across all niches' but does not specify fields or format, leaving a significant gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description adds an example ('beginner mistakes {niche}') but does not provide additional meaning beyond the well-documented schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: running an outlier search per niche by substituting a phrase template, ranking hits across niches. It answers a specific question and distinguishes from siblings like find_outliers.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description warns about the high cost (percent of daily quota), implying it should be used sparingly and for cross-niche comparison. However, it doesn't explicitly state when not to use it or direct users to an alternative for single-niche searches.
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.
4 tool updates
v0.3.0- First observed
find_outliers - First observed
get_comment_signal - First observed
get_video_structure - First observed
search_niche_sweep
TDQS
Scored across 4 tools
Each tool targets a distinct step in the outlier analysis workflow: finding outliers, analyzing comments, extracting video structure, and running batch niche searches. No two tools overlap in purpose.
All tool names follow a consistent verb_noun pattern in snake_case (find_outliers, get_comment_signal, get_video_structure, search_niche_sweep), making them predictable.
With 4 tools, the set is slightly lean but appropriate for a specialized YouTube outlier analysis server. Each tool addresses a core function without unnecessary redundancy.
The tools cover the main outlier identification and validation pipeline: search, comment analysis, and structure extraction. Missing channel-level details or result persistence are minor gaps given the focused scope.
Maintenance
Related MCP Connectors
Find YouTube outliers, daily viral Shorts, and analyze video performance.
Find viral outlier posts on TikTok, Instagram and YouTube, pull creator stats, and crawl on demand.
Audits any YouTube channel against its own history. Every claim carries its sample size.
YouTube public video, comment, reply, channel, search, and speech-to-text transcript tools.
Related MCP Servers
- AlicenseBqualityCmaintenanceEnables extraction of transcripts, keyword-based video search with metadata retrieval, and channel information discovery from YouTube videos through natural language interaction.34MIT
- AlicenseCqualityDmaintenanceEnables AI assistants to research YouTube videos by collecting captions, comments, and channel information for analysis and comparison.109MIT
- FlicenseAqualityCmaintenanceEnables AI assistants to analyze YouTube channels, videos, transcripts, and content strategy through structured tool calls.1717-
- FlicenseNot gradedqualityCmaintenanceEnables YouTube competitor research, signal analysis, and transcript-aware pack building for content ideation and scriptwriting.1-