This server is an MCP interface to a local YouTube evidence knowledge base: it can ingest transcripts, search them, and report what it has learned.
get_transcript: fetch a YouTube video's transcript (optionally translated/stored) or return full stored transcript.
research_topic: research a topic by ingesting transcripts from top YouTube videos into the growing local knowledge base.
search_knowledge: retrieve relevant transcript passages with timestamped deep links, optionally filtered by topic.
knowledge_stats: report learned videos, chunks, topics, and embedding status.
Provides tools for researching YouTube videos by topic, fetching transcripts from video URLs or IDs, and searching an accumulated local knowledge base with timestamped deep links to the exact source moments.
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., "@ytscholar research the history of the Roman Empire"
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.
A local YouTube evidence layer (MVP). It finds the top YouTube videos on a topic, pulls their transcripts, and grows a local knowledge base — then exposes searchable, source-aware evidence and full transcripts to LLM clients, so the model can research, compare sources, and synthesize with citations you can verify by clicking.
It runs entirely on your machine: no API keys, no cloud service, no subscription. You can use it from the CLI or as an MCP server inside Claude Desktop, Cursor, Cline, or any MCP-compatible client.
Design boundary: ytscholar collects, stores, and retrieves evidence. It does not reason — no claim extraction, no summarizing, no contradiction detection. Analysis and synthesis belong to the LLM client consuming this data.
Status: MVP. The core loop — research → store → evidence retrieval with timestamped citations — works and is covered by offline tests (the network path was also validated manually against real YouTube). It is deliberately small. See Limitations for what it is not.
Research a topic. Give it a subject; it finds the top YouTube videos for it, fetches their transcripts, and ingests them into a local knowledge base.
Transcribe a link. Give it a video URL/id; it returns the full transcript (with optional machine translation).
Search what it has learned. Ask a question; it retrieves the most
relevant passages from everything ever ingested, each with a deep link
that opens the source video at the right moment
(https://youtu.be/VIDEO_ID?t=SECONDS).
Retrieve evidence, source-aware. The same retrieval, grouped by video and channel — so a model (or you) can see whether the evidence comes from genuinely different sources or from one channel repeated.
No YouTube Data API key is required. Search uses yt-dlp; transcripts use
youtube-transcript-api with a yt-dlp caption-download fallback.
Related MCP server: YouTube Knowledge Base MCP
Fetching one transcript is a solved problem — several tools do it. ytscholar's value is the accumulation and the evidence layer: every ingest grows a persistent local knowledge base, and retrieval returns evidence with precise, clickable sources plus source-diversity analysis. An LLM client can search for evidence, judge how independent the sources are, and pull a full transcript when it needs complete context — then do the actual reasoning itself. That makes ytscholar a small "research memory" you own: a SQLite file you can back up, inspect, or delete.
Exactly what the code does today — ytscholar ends at evidence; the LLM client does the analysis:
YouTube
↓
Video Discovery yt-dlp ytsearch{N} (YouTube's own ranking);
hard cap per run (default 15); 30-day cache
↓
Full Transcript youtube-transcript-api (primary)
→ yt-dlp caption download + VTT parse (fallback)
↓
┌─────────────────────┬───────────────────────────────────────────┐
│ Full Transcript │ Chunking (~900 chars; each chunk keeps │
│ Storage │ its start timestamp) → FTS5 index │
└─────────────────────┴───────────────────────┬───────────────────┘
↓
Evidence Retrieval passages + video/channel grouping
(FTS5 bm25; optional experimental re-rank)
↓
LLM client analysis + synthesis ← not part of
(Claude / GLM / …) with verifiable citations ytscholarytscholar never discards the full transcript: chunking and FTS5 exist for
retrieval; get_transcript always returns the complete stored text.
Only what exists and works today:
5 CLI commands: research, transcript, search, evidence, stats
5 MCP tools over the same core: research_topic, get_transcript,
search_knowledge, search_evidence, knowledge_stats
Keyword retrieval via SQLite FTS5 with bm25 ranking; optional topic filter
Evidence retrieval: passages grouped by video and channel, with
unique_channels, channel_distribution, and an independence warning
(deterministic — channel variety only, no AI)
Full transcripts kept in the DB and retrievable at any time
Timestamped deep links on every search/evidence hit
Per-video failure isolation — one broken video never kills a research run
Politeness rails: hard per-run video cap, delay between requests, 30-day cache (no re-fetching what it already knows)
Proxy and browser-cookie support for restricted networks (validated against a real filtered-network setup)
Clean, actionable CLI errors instead of tracebacks
Offline test suite (15 tests: URL/VTT parsing, chunking, storage, FTS retrieval, cache freshness, topic filter) + CI on Python 3.10–3.12
The package is not on PyPI yet — install from source:
git clone https://github.com/Elahe-z/ytscholar
cd ytscholar
pip install -e . # core: CLI + MCP server, keyword (FTS5) retrievalPython 3.10+ is required. The optional [embeddings] extra is described in
Search.
All configuration is via environment variables (no config files, no secrets in the repo):
Variable | Default | Meaning |
|
| Base dir for the knowledge DB |
|
| Preferred transcript languages, e.g. |
|
| Hard cap on videos per research call |
|
| Seconds between transcript fetches |
|
| Skip re-fetching a video seen within N days |
|
|
|
|
| sentence-transformers model |
|
| Approx chars per retrieval chunk |
| (from | Proxy for reaching YouTube |
| (from | HTTPS proxy for reaching YouTube |
| (unset) | Browser to read YouTube cookies from ( |
| (unset) | Path to an exported |
# Learn a topic from its top videos (English topics give the best ranking):
ytscholar-cli research "retrieval augmented generation" --max 5
# Ask questions about everything learned so far:
ytscholar-cli search "how does RAG reduce hallucinations"
# Evidence with source/channel analysis (human-readable):
ytscholar-cli evidence "how does RAG reduce hallucinations" --pretty
# Get one video's transcript without storing it:
ytscholar-cli transcript "https://youtu.be/VIDEO_ID" --text-only --no-store
# What does the agent know?
ytscholar-cli statsOn a network where YouTube is filtered, point the agent at your proxy first — see Restricted networks.
Tip: transcripts are usually English, so phrase search queries in English
for the best keyword matches.
Search is keyword-based by default:
The query is sanitized (alphanumeric tokens only — no FTS syntax injection is possible) and turned into an OR-query of its word tokens.
SQLite FTS5 matches chunks with bm25 ranking (lower = better) over the entire knowledge base, optionally filtered by topic (exact match).
A wider candidate pool (≥30) is fetched, ranked, and the top k returned.
Each hit carries video_id, title, channel, start_seconds, text,
score, and a link deep link built from the chunk's stored start time.
Optional semantic re-rank (experimental). With
pip install "ytscholar[embeddings]" (pulls in torch, hundreds of MB) and
YTSCHOLAR_EMBEDDINGS=1, chunks are embedded at ingest time and query
vectors re-rank the FTS candidates by cosine similarity. This path is
implemented but experimental: it is not covered by the test suite and is
disabled by default. Without it, everything works via plain keyword search.
Known search limitations (see also Limitations): queries are matched as OR-ed words (no quoted-phrase support), and there is no synonym matching in keyword mode.
ytscholar-cli evidence / MCP search_evidence runs the same retrieval
engine, then groups the hits so source diversity is visible:
{
"passages": [
{
"video_id": "…", "title": "…", "channel": "…",
"start_seconds": 763.1,
"link": "https://youtu.be/…?t=763",
"text": "…passage text…", "score": 7.85
}
],
"videos": [
{ "video_id": "…", "title": "…", "channel": "…", "url": "…", "passages": 3 }
],
"unique_channels": 2,
"channel_distribution": { "Channel A": 3, "Channel B": 1 },
"independent": false,
"warning": "3 of 4 matching videos come from the same channel ('Channel A'). Evidence may not be fully independent."
}The point: N passages do not mean N sources. If four matching videos come
from two channels — three of them from the same one — the model should know
that. independent is a deterministic channel-variety heuristic (true = no
single channel holds a strict majority of the matching videos); it makes no
stronger epistemic claim. Typical model workflow:
search_evidence(query) → judge sources → get_transcript(video_id) for any
source that needs full context → synthesize with citations.
research_topic(topic, max_videos) does exactly this, in order:
Clamps the video count to min(max_videos, YTSCHOLAR_MAX_VIDEOS).
Searches YouTube via yt-dlp (ytsearchN, flat metadata) — the order is
YouTube's own relevance ranking.
For each result: if the video was fetched within the cache TTL
(default 30 days), it is marked cached and skipped — no re-download.
Otherwise the transcript is fetched (primary API, then yt-dlp fallback), chunked (~900 chars, timestamps preserved), and stored under that topic.
A short polite delay runs between videos.
One video failing (no captions, network error) only marks that video
no_transcript / error with the reason — the run continues.
Returns a per-video report plus overall knowledge-base stats.
Statuses you will see: ingested, cached, no_transcript, error.
Single SQLite database: ~/.ytscholar/knowledge.db (override the location
with YTSCHOLAR_HOME).
Tables: videos (metadata + full transcript text + fetched_at) and
chunks (text, start time, optional embedding), plus an FTS5 full-text
index kept in sync by triggers. WAL mode for safe concurrent reads.
The DB is the agent's memory: it persists across sessions, it is safe to copy/back up, and deleting it resets what the agent knows.
It lives outside the repository — no personal data ships with the code.
An MCP server over stdio ships with the package (ytscholar command). Same
five operations as the CLI, for use inside Claude Desktop, Cursor, Cline, …
(research_topic, get_transcript, search_knowledge, search_evidence,
knowledge_stats). Designed for the model workflow:
research_topic to ingest → search_evidence to find evidence and judge
source diversity → get_transcript(video_id) when full context is needed →
the model does the analysis and synthesis.
Claude Desktop (claude_desktop_config.json):
{
"mcpServers": {
"ytscholar": {
"command": "ytscholar",
"env": {
"YTSCHOLAR_DEFAULT_LANGS": "en",
"YTSCHOLAR_HTTPS_PROXY": "http://127.0.0.1:12334"
}
}
}
}Cursor (~/.cursor/mcp.json):
{ "mcpServers": { "ytscholar": { "command": "ytscholar" } } }If ytscholar is not on the client's PATH, use the absolute path
(which ytscholar) or "command": "python", "args": ["-m", "ytscholar.server"].
Example prompts once connected: "Research 'retrieval augmented generation' from the top 5 YouTube videos", then "From what you've learned, how does re-ranking improve RAG?" — answers come with timestamped citations.
Honest list for this MVP:
Keyword search only (by default): OR-ed word tokens, no phrase support, no synonyms. English queries against English transcripts work well; Persian queries won't match English content.
Semantic re-rank is experimental — implemented, off by default, not covered by tests.
independent in evidence retrieval is a heuristic: it reflects channel
variety only (same-creator concentration), not true epistemic independence
— two channels may still repeat the same primary source.
get_transcript returns the full transcript text; for very long videos
this is a large payload for an LLM context.
A single-video transcript stores the URL you passed as the video title
in the knowledge base (real title enrichment is not implemented).
The topic filter is an exact, case-sensitive match on the string passed
to research.
Ingest relies on scraping (yt-dlp / youtube-transcript-api): YouTube
layout changes or IP blocks can break it. Cookies/proxy options mitigate.
Video selection trusts YouTube's ranking as-is: no duration, language, or caption-availability filtering up front.
Not implemented — kept deliberately out of this MVP:
Claim extraction, contradiction detection, source lineage, evidence graphs (these are the LLM client's job; future versions may assist with them)
Quoted-phrase queries and per-video diversity in search results
Real title/metadata enrichment for single-video transcripts; transcript length caps for LLM consumption
Validate and test the embeddings path; make semantic mode first-class
Optional tiny HTTP API over the same core, for workflow tools (n8n etc.)
Publish to PyPI (pip install ytscholar)
If pip install fails with No matching distribution found, your network is
blocking pypi.org. Point pip at a local mirror:
pip install -e . -i https://mirror-pypi.runflare.com/simple/ \
--trusted-host mirror-pypi.runflare.comTo reach YouTube itself, run your VPN/proxy and point the agent at it:
export YTSCHOLAR_HTTPS_PROXY="http://127.0.0.1:PORT"
ytscholar-cli transcript "https://youtu.be/VIDEO_ID" --text-onlyHiddify users: the local mixed (HTTP+SOCKS) port is 12334 once the core is connected, so:
export YTSCHOLAR_HTTPS_PROXY=http://127.0.0.1:12334(Ports like17078belong to the app itself, not the proxy — they refuse connections.)
If YouTube answers IpBlocked / "Sign in to confirm you're not a bot"
(common on VPN/datacenter IPs), pass your browser's cookies:
export YTSCHOLAR_COOKIES_FROM_BROWSER="firefox" # or chrome / brave / edgeOr export a cookies.txt (browser extension) and set
YTSCHOLAR_COOKIES_FILE=/path/to/cookies.txt.
pip install -e ".[dev]"
pytest -q # offline tests only — no network neededCI (.github/workflows/ci.yml) runs this suite on Python 3.10–3.12 for every
push and pull request.
MIT — see LICENSE.
Return the transcript/subtitles for a single YouTube video.
Args: video: A YouTube URL or an 11-character video id. languages: Optional comma-separated preferred languages in priority order, e.g. "en" or "fa,en". Empty = server default. translate_to: Optional target language code to auto-translate the transcript into (uses YouTube's translation), e.g. "en". store: If true (default), also add this transcript to the local knowledge base so future searches can draw on it.
Returns a dict with the plain-text transcript, language, and metadata.
| Name | Required | Description | Default |
|---|---|---|---|
| store | No | ||
| video | Yes | ||
| languages | No | ||
| translate_to | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It explicitly states that the store parameter defaults to true and adds the transcript to the local knowledge base, a side effect. It also specifies the return value as a dict with plain-text transcript, language, and metadata, covering the main behavior adequately.
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 structured with a clear first line, an Args block, and a Returns line, making it easy to scan. It is moderately long but every sentence adds value, including examples and defaults. It is appropriately front-loaded with the purpose, though slightly verbose in the Args section.
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?
For a tool with four parameters, no output schema, and no annotations, the description is quite complete. It covers all parameters, the return value, and the store side effect. It does not address error handling or edge cases (e.g., missing transcript), but these are not essential for basic usage and would likely be surfaced through other means.
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 0%, so the description must compensate, and it does so fully. It explains video as a URL or 11-character ID, languages as comma-separated with priority order and a default, translate_to as a target language code, and store with its default and side effect. Every parameter is clearly documented with examples and defaults.
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 starts with 'Return the transcript/subtitles for a single YouTube video,' which is a specific verb and resource. It clearly distinguishes this tool from siblings like research_topic, search_knowledge, and knowledge_stats, none of which relate to transcript retrieval. The purpose is unambiguous and immediately actionable.
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 does not explicitly state when to use this tool versus alternatives, but the purpose is self-evident from the name and opening line, so usage is implied. It provides context for the store parameter, indicating when to persist transcripts for later search. However, there is no mention of exclusions or alternative tools for similar tasks, which would have earned a higher score.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Report what the agent has learned so far: videos, chunks, topics, and whether semantic embeddings are active. Useful to check memory state.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It discloses that this is a non-mutating status inspection by saying 'Report' and 'check memory state,' and it adds a specific behavioral detail about semantic embeddings being active. It does not explicitly state 'read-only' or describe side effects, but the wording strongly implies a safe diagnostic operation.
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 with no wasted words. It front-loads the core purpose, lists the report contents, and then gives a usage cue. This is appropriately sized and easy to scan.
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?
For a zero-parameter status tool with no output schema, the description covers what the tool reports and when it is useful. It does not provide an exact output shape, but the enumerated categories give sufficient context for an agent to invoke it correctly.
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 tool has zero parameters and schema coverage is 100%, so there are no parameter semantics to clarify. The description adds value by enumerating what the report includes, which is the relevant semantic content for a no-argument tool.
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 uses a specific verb ('Report') and names the resource ('what the agent has learned so far'), with concrete report contents: videos, chunks, topics, and embedding status. This clearly distinguishes it from sibling tools like get_transcript, research_topic, and search_knowledge, which are retrieval/research operations.
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 phrase 'Useful to check memory state' provides a clear context for when to invoke this tool. It does not explicitly mention alternatives or exclusions, but the status-report nature is evident enough among the listed siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Research a topic by mining the transcripts of the top YouTube videos.
Searches YouTube for the topic, takes the top max_videos results, pulls
each transcript, and ingests them into the agent's growing knowledge base.
This is how the agent "learns" a subject. Use search_knowledge afterward
to ask questions grounded in what was ingested.
Args: topic: The subject to research, e.g. "retrieval augmented generation". max_videos: How many top videos to mine (capped by server config). languages: Optional comma-separated preferred transcript languages.
Returns a per-video ingestion report plus updated knowledge-base stats.
| Name | Required | Description | Default |
|---|---|---|---|
| topic | Yes | ||
| languages | No | ||
| max_videos | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the transparency burden and largely succeeds: it discloses the external YouTube search, the max_videos cap, transcript extraction, and ingestion into the knowledge base. It also states the return artifact. It doesn't mention failure modes or rate-limit implications, but the core behavioral contract is clear.
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 structured into a summary, workflow context, and an Args/Returns block, making it easy to scan. A few phrases are slightly redundant (the first two sentences both describe searching and mining), but no filler sentences exist.
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?
For a tool with no annotations and no output schema, the description covers what it does, how it changes state, the meaning of every parameter, and what is returned. It lacks edge-case details such as what happens when no transcripts are found or the actual server cap, but those are not needed to invoke the tool correctly.
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 descriptions are absent (0% coverage), and the description compensates by defining all three parameters with meaningful detail: topic with an example, max_videos as a server-capped count, and languages as optional comma-separated preferences. This goes well beyond the bare 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 opening sentence specifies a concrete action ('research a topic') and a distinctive method ('mining transcripts of top YouTube videos'), separating it from generic search or retrieval tools. It also identifies the knowledge-base ingestion side effect, so an agent can recognize it as a learning/research capability.
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 explicitly frames this as the way the agent learns a subject and instructs using search_knowledge afterward, giving a clear follow-up workflow. It doesn't spell out when to prefer get_transcript or when not to use this tool, so it stops short of a full decision rule.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Semantic/keyword search over everything the agent has already learned.
Retrieves the most relevant transcript passages from the local knowledge base, each with a deep link that opens the source video at the exact timestamp. Answer the user's question using these passages as evidence.
Args: query: Natural-language question or keywords. k: Number of passages to return. topic: Optional filter to a topic previously passed to research_topic.
| Name | Required | Description | Default |
|---|---|---|---|
| k | No | ||
| query | Yes | ||
| topic | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden, and it does so well: it clarifies this is a retrieval operation, describes the returned artifact (passages with deep links and timestamps), and frames the intended follow-up behavior (answer using them as evidence). It does not discuss auth, rate limits, or failure modes, but for a read-only search tool this is suitably transparent.
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 compact, front-loaded with the core operation, then adds output details, usage instruction, and an Args block. Every section adds distinct value: the Args block is especially helpful given the empty schema descriptions.
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 no output schema, the description still explains what will be returned: most relevant transcript passages, each with a deep link and exact timestamp. It also gives enough context to use the tool responsibly, though it could more explicitly differentiate from get_transcript for agents deciding between retrieval tools.
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 0%, so the description is the only source of parameter meaning, and it fully compensates. It explains query as natural-language/keywords, k as number of passages, and topic as a filter tied to a prior research_topic invocation—each more informative than the bare schema titles.
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?
Names a specific operation ('Semantic/keyword search') and resource ('everything the agent has already learned', 'local knowledge base', 'transcript passages'), with a clear outcome: retrieve relevant passages with deep links to source videos. This distinguishes it from siblings like get_transcript (raw transcript retrieval) and research_topic (topic creation).
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 gives clear context: use this when answering a user's question from previously learned material. It instructs the agent to use returned passages as evidence. It does not explicitly name alternatives or when-not-to-use cases, so it falls just short of full guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.0get_transcriptknowledge_statsresearch_topicsearch_knowledgeScored across 4 tools
Each tool has a clearly distinct purpose: fetching transcripts, researching a topic (which itself uses transcripts), searching the knowledge base, and reporting stats. Even though research_topic uses get_transcript internally, their high-level functions are unambiguous.
All tools follow a verb_noun pattern: get_transcript, research_topic, search_knowledge, knowledge_stats. The pattern is consistent, though 'research_topic' and 'knowledge_stats' are slightly less uniform than 'get_' or 'search_' prefixes, but still readable.
With only 4 tools, the set is lean and well-scoped for a YouTube transcript knowledge-base server. Each tool is essential: ingestion (get_transcript), bulk learning (research_topic), retrieval (search_knowledge), and monitoring (knowledge_stats). No bloat.
The core workflow of ingest, research, search, and stats is covered. Minor gaps include lack of a tool to delete knowledge or list all topics explicitly, but these are not critical for the primary use case of learning and querying.
Transcribe YouTube via Whisper. Summaries, chapters, semantic-search across your corpus.
Personal YouTube AI knowledge base powered by RAG. Query your subscribed YouTube channels.
YouTube transcripts, search, channel/playlist listings and upload tracking for AI agents.
Extract YouTube transcripts, search what was said, and read on-screen frames with cited timestamps.
