Provides tools for searching YouTube videos, retrieving video metadata and transcripts, pinpointing specific topics within videos, and conducting multi-video research with source diversity and evidence clustering.
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., "@YouTube Research MCP Find videos on quantum computing and extract their transcripts"
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.
Understand Everything. Instantly.
Nexora is a high-performance, model-agnostic intelligence platform for deep video, transcript, and multimodal research. Nexora MCP connects AI pair programmers, reasoning agents, and LLMs (ChatGPT, Claude, Gemini, Cursor, Codex, OpenCode) directly to YouTube as a structured, verifiable knowledge base with zero API keys required.
Branding & Migration Notice: This project is transitioning to the Nexora master brand. During this transition period, the repository and Python package maintain youtube-research-mcp as the backwards-compatible legacy technical identifier. All existing client configurations and tool schemas remain 100% compatible.
Connect your favorite MCP client immediately without local installation:
https://youtube-research-mcp-production.up.railway.app/mcpProtocol: mcp-2024-11-05
Transport: Streamable HTTP / SSE
Authentication: None required for public MCP tool access (Rate-limited Token Bucket protected)
Related MCP server: youtube-mcp
Measured directly on Windows 11 / Python 3.11 with SQLite WAL Mode & FastMCP in-process execution:
Operation | Fresh Latency (P50) | Cached Latency (P50) | Cached Latency (P95) | Concurrency (100 reqs) |
| ~7.4 ms | ~7.1 ms | ~7.8 ms | 2.83 ms / req |
| ~6.5 ms | ~5.8 ms | ~6.4 ms | 2.10 ms / req |
| ~8.0 ms | ~6.5 ms | ~7.7 ms | 2.45 ms / req |
| ~20.9 ms | ~18.2 ms | ~46.1 ms | 6.10 ms / req |
Workload | Concurrency | P50 Latency | P95 Latency | P99 Latency | Throughput | Single-Flight Coalesced |
Cached Workload | 10 reqs | 0.029 ms | 0.045 ms | 0.049 ms | 4,080 req/s | 0 (Direct Cache Hits) |
Cached Workload | 50 reqs | 0.019 ms | 0.031 ms | 0.041 ms | 12,616 req/s | 0 (Direct Cache Hits) |
Cached Workload | 100 reqs | 0.022 ms | 0.027 ms | 0.030 ms | 8,411 req/s | 0 (Direct Cache Hits) |
Fresh Retrieval Workload | 10 reqs | 2.41 ms | 3.44 ms | 3.88 ms | 377 req/s | 9 coalesced (1 in-process execution) |
Fresh Retrieval Workload | 50 reqs | 2.13 ms | 3.16 ms | 3.69 ms | 426 req/s | 49 coalesced (1 in-process execution) |
Fresh Retrieval Workload | 100 reqs | 3.39 ms | 4.41 ms | 4.79 ms | 310 req/s | 99 coalesced (1 in-process execution) |
Benchmark Transparency Notice: The reported throughput numbers measure in-process async single-flight coalescing and in-memory retrieval performance (e.g. coalescing 100 concurrent AI agent queries onto a single execution to protect downstream systems). They do NOT represent raw/fresh YouTube HTTP request throughput. Real-world un-cached network requests to YouTube remain subject to standard network latency and YouTube's per-IP rate limits.
AI Agent (ChatGPT / Claude / Cursor / OpenCode)
│
▼ (Streamable HTTP / stdio / SSE)
FastMCP Server (Port 8000)
├── Bounded LRU Retrieval Index Cache (MAX=100, TTL=1hr)
├── Metrics & Observability Collector (`youtube://health`, `/api/admin/metrics`)
└── Pluggable Cache Layer (SQLite WAL / Redis / Memory with Negative Caching & Auto-Purge)
│
▼
SingleFlight Request Coalescer (Zero Cache Stampedes)
│
▼
Capability-Aware Circuit Breakers (CLOSED / OPEN / HALF_OPEN)
├── Search Capability
├── Metadata Capability
└── Transcript Capability
│
▼
Multi-Tier Provider Routing
├── Tier 1: Direct InnerTube (Shared HTTP/2 Connection Pool) / yt-dlp (Anti-Bot Rotation)
├── Tier 2: yt-dlp Fallback Extraction / InnerTube Fallback
└── Tier 3: Commercial Fallbacks (Supadata)Anti-Bot Client Rotation Engine: Automatically rotates player clients across android, ios, tv_embedded, and mweb without cookies or API keys.
Pluggable Caching Architecture:
SQLite: Local SQLite WAL database with auto-pruning at MAX_CACHE_ENTRIES and TTL expiration.
Redis: Production Redis integration with connection pooling, secret masking, and universal Redis 5.x/6.x/7.x compatibility via RESP2 (protocol=2).
Memory: High-speed in-process thread-safe dictionary cache.
Capability-Level Circuit Breaker: State machine (CLOSED $\rightarrow$ OPEN $\rightarrow$ HALF_OPEN with 1-probe concurrency lock) tracked individually for search, metadata, and transcript capabilities.
Single-Flight Request Coalescing: Prevents cache stampedes by merging duplicate in-flight requests into a single upstream execution.
Multilingual Unicode Tokenization: Native token splitting across Hindi (Devanagari), CJK (Chinese, Japanese), Korean (Hangul), Arabic, Cyrillic, and Latin scripts.
Hybrid Semantic Retrieval (In-Process): BM25s sparse retrieval fused via Reciprocal Rank Fusion (RRF) with dense vector embeddings / TF-IDF.
Multi-Video Research & Evidence Clustering: Autonomous cross-video discovery with source channel diversity (max_videos_per_channel=2) and near-duplicate claim clustering.
Security & Production Hardening:
Constant-time Admin API Key authentication (X-Admin-Key / Authorization: Bearer <KEY>).
Strict CORS origin validation for public and administrative endpoints.
Per-IP Token-Bucket rate limiting on REST endpoints.
Resource-safe query length and transcript segment bounding (MAX_TRANSCRIPT_SEGMENTS, MAX_QUERY_LENGTH).
youtube_searchSearches YouTube videos with deterministic post-filtering for dates and languages.
query (string, required)
max_results (int, default: 5, max: 25)
language (string, default: "en")
published_after (ISO date string YYYY-MM-DD, optional)
published_before (ISO date string YYYY-MM-DD, optional)
youtube_videoRetrieves video metadata, view counts, upload date, tags, and chapter markers.
video_id (string, required): 11-char ID or YouTube URL.
youtube_transcriptExtracts spoken transcripts with timestamp deep links and explicit language provenance.
video_id (string, required)
language (string, default: "en")
fallback_language (string, default: "en", or null to disable)
include_timestamps (bool, default: True)
translate_to (string, optional)
youtube_find_in_videoPinpoints exact sections in long videos discussing a specific topic using hybrid RRF search.
video_id (string, required)
query (string, required)
max_results (int, default: 5)
language (string, default: "en")
fallback_language (string, default: "en")
youtube_researchMulti-video research discovery across diverse channels with near-duplicate claim clustering.
query (string, required)
depth ("quick" = 2 videos, "standard" = 3 videos, "deep" = 5 videos)
max_videos_per_channel (int, default: 2)
language (string, default: "en")
fallback_language (string, default: "en")
published_after (ISO date string YYYY-MM-DD, optional)
published_before (ISO date string YYYY-MM-DD, optional)
# Clone the repository
git clone https://github.com/Unknowmyt1M/youtube-research-mcp.git
cd youtube-research-mcp
# Install dependencies using uv (recommended)
uv sync
# Run the MCP Server locally over Streamable HTTP
uv run python -m youtube_research_mcp.server --transport http --port 8000Deploy this server to Railway, Render, Fly.io, or Docker to expose a unified remote endpoint for all your AI agents and coding tools:
https://<your-production-domain>/mcpConnect your GitHub repository to Railway.
Railway detects Dockerfile and railway.json automatically.
Configure Environment Variables (optional: ADMIN_API_KEY, REDIS_URL).
Railway automatically sets dynamic $PORT and routes container traffic.
In Networking, click Generate Domain (e.g. https://youtube-mcp-production.up.railway.app).
Verify Health: GET https://<your-domain>/ (returns HTTP 200).
Use your hosted endpoint https://<your-domain>/mcp across any MCP-compatible AI client:
opencode.json / opencode.jsonc){
"mcp": {
"servers": {
"youtube-research": {
"type": "remote",
"url": "https://<your-domain>/mcp"
}
}
}
}~/.cursor/mcp.json){
"mcpServers": {
"youtube-research": {
"url": "https://<your-domain>/mcp"
}
}
}.vscode/mcp.json){
"servers": {
"youtube-research": {
"type": "http",
"url": "https://<your-domain>/mcp"
}
}
}cline_mcp_settings.json){
"mcpServers": {
"youtube-research": {
"type": "streamableHttp",
"url": "https://<your-domain>/mcp",
"disabled": false,
"autoApprove": []
}
}
}~/.codeium/windsurf/mcp_config.json){
"mcpServers": {
"youtube-research": {
"serverUrl": "https://<your-domain>/mcp"
}
}
}In ChatGPT Developer / Custom Actions Settings:
https://<your-domain>/mcpclaude_desktop_config.json){
"mcpServers": {
"youtube-research": {
"command": "uv",
"args": [
"--directory",
"/path/to/youtube-research-mcp",
"run",
"python",
"-m",
"youtube_research_mcp.server",
"--transport",
"stdio"
]
}
}
}# Run full unit and integration test suite (121 tests)
uv run pytest -v
# Run deterministic retrieval evaluation benchmark (Recall@1, MRR, timestamp accuracy)
uv run python tests/evaluation/evaluate_retrieval.py
# Run real Redis integration tests (requires local or remote Redis)
uv run pytest tests/integration/test_redis_live.py -v
# Run reproducible high-concurrency load benchmark (10, 50, 100 concurrent reqs)
uv run python tests/benchmarks/test_load_harness.py
# Run latency and concurrency benchmarks
uv run pytest tests/benchmarks/test_latency.py -s
uv run pytest tests/benchmarks/test_concurrency_benchmarks.py -sMIT License. Free for open-source and commercial AI agent workflows.
Pinpoint exact sections and timestamps in a long video where a specific topic or concept is discussed. Uses in-process Hybrid RRF (FastEmbed ONNX dense vectors + BM25 lexical search) to locate the most relevant 2-3 minute chunks. Returns deep-link timestamp URLs (e.g. ?t=842s), relevance scores, chapter context, and exact spoken quotes. PREFERRED over reading full transcripts for videos longer than 10 minutes.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | The specific question, topic, or concept to find inside the video | |
| language | No | Transcript language code | en |
| video_id | Yes | 11-character YouTube video ID or full YouTube URL | |
| max_results | No | Number of relevant sections to retrieve (1-10) |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It explains the underlying search mechanism (Hybrid RRF with FastEmbed ONNX and BM25) and precisely what is returned: deep-link URLs, relevance scores, chapter context, and spoken quotes. This is transparent about the tool's operation and output. It doesn't mention any side effects or prerequisites, but for a read-only search tool, the disclosed behavior is sufficiently 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 concise, with the core purpose front-loaded in the first sentence, followed by technical details and a usage recommendation. It wastes no words and is easy to scan. It could be slightly more structured (e.g., separating the technical method from the usage note), but it is efficient and appropriately sized.
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?
An output schema is present (indicated by 'Has output schema: true'), so the description doesn't need to detail return values, but it does list the key output elements (URLs, scores, chapter context, quotes) which helps agents understand what to expect. It lacks explicit mention of error conditions or prerequisites (e.g., transcript availability), but given the tool's simplicity and the schema coverage, it is reasonably complete for an agent to call 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 schema has 100% description coverage, so the baseline is 3. The description adds minimal extra meaning beyond the schema: it rephrases 'query' as 'specific question, topic, or concept' and mentions output types, but it does not elaborate on parameter specifics like language or max_results behavior beyond what the schema already provides. Thus, it meets the baseline without adding substantial value.
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: pinpoint exact sections and timestamps in a long video for a specific topic. It uses a specific verb (pinpoint), a specific resource (long video), and distinct output details (deep-link URLs, relevance scores, quotes). It also distinguishes itself from siblings like youtube_transcript by explicitly positioning itself as the preferred tool over full transcripts for long videos.
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 concrete usage guidance: it is 'PREFERRED over reading full transcripts for videos longer than 10 minutes.' This implies when to use it (long videos) and contrasts with the transcript tool. It doesn't explicitly mention alternatives like youtube_search or youtube_research, but the context is clear. A minor gap is not specifying when not to use it beyond the transcript context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Autonomous multi-video research tool. Discovers relevant YouTube videos across diverse channels, extracts spoken transcripts concurrently, performs semantic search, and aggregates timestamped citations with near-duplicate claim clustering.
| Name | Required | Description | Default |
|---|---|---|---|
| depth | No | Research depth: 'quick' (2 videos), 'standard' (3 videos), or 'deep' (5 videos) | standard |
| query | Yes | Broad research topic, question, or technology to investigate across YouTube | |
| language | No | Target video search and transcript language | en |
| published_after | No | Optional ISO date filter (YYYY-MM-DD) to research only recent videos | |
| published_before | No | Optional ISO date filter (YYYY-MM-DD) | |
| fallback_language | No | Fallback transcript language if requested language is unavailable | en |
| max_videos_per_channel | No | Maximum videos to include from any single channel (source diversity) |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits on its own. It describes the internal process (discovery, concurrent transcript extraction, semantic search, clustering) but does not mention key constraints like read-only nature, potential duration (multi-step autonomous tool likely takes time), or any side effects. It is informative but incomplete regarding operational boundaries.
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 a single sentence that front-loads the core purpose ('Autonomous multi-video research tool') and then lists key capabilities efficiently. It is concise but slightly run-on, packing many clauses together. Still, it earns its place with 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 tool is complex (7 parameters, autonomous behavior) and has an output schema, so return values need not be described. However, the description omits practical context such as that the tool may be long-running or resource-intensive, and it does not mention any limitations or prerequisites. Given no annotations, the description carries the full burden and leaves gaps that an agent might need for correct usage.
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 input schema covers 100% of parameters with descriptions, so the baseline is 3. The description does not add any parameter-specific meaning beyond what the schema already provides; it only gives a high-level overview. No extra value is contributed here.
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 states a clear, specific purpose: an autonomous multi-video research tool that discovers videos, extracts transcripts, performs semantic search, and produces timestamped citations with clustering. This clearly distinguishes it from sibling tools like youtube_search or youtube_transcript, which handle individual operations. The verb 'research' and resource 'multi-video' make its scope unambiguous.
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 implies use for broad research across multiple videos, but it does not explicitly state when to use this tool versus the siblings (e.g., 'for a single video use youtube_video'). There are no when-not-to-use conditions or named alternatives. The context is clear enough to infer the intended use, but guidance is not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search YouTube for videos matching a query without needing an API key. Returns a structured list of videos with IDs, titles, channels, durations, views, and URLs. Use this tool when you need to discover videos on a topic or find candidate videos for research.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Search keywords or research topic | |
| language | No | Preferred language code (e.g. 'en', 'es', 'hi') | en |
| max_results | No | Maximum number of video results to return (1-25) | |
| published_after | No | Optional ISO date filter (YYYY-MM-DD) | |
| published_before | No | Optional ISO date filter (YYYY-MM-DD) |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden of behavioral disclosure. It adds useful context like 'without needing an API key' and describes the return shape, but it does not disclose potential limitations such as rate limits, result freshness, ranking behavior, or possible unreliability. This is acceptable but leaves room for more transparency.
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?
Two sentences with no filler. Key behavioral information is front-loaded, and the usage guidance is appended cleanly. Every sentence earns its place.
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 a complete input schema and an output schema present, the description covers the essential context. It could be more complete by explicitly positioning itself against youtube_research, but an agent can still select and invoke it correctly based on the current wording and schema.
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 the baseline is 3. The description adds little beyond the schema: it emphasizes querying and returning structured results but does not clarify parameter semantics or formats beyond what the input schema already documents.
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 action ('Search YouTube'), the target resource, and the specific output (structured list with IDs, titles, channels, durations, views, URLs). It also frames the tool's niche as discovery and candidate selection, which distinguishes it from siblings like youtube_transcript or youtube_video.
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 says to use it when discovering videos on a topic or finding candidates for research. It does not mention when not to use it or compare directly with alternatives such as youtube_research, but the guidance is clear enough for common use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Extract the spoken transcript of a YouTube video with timestamped segments and language provenance. Returns requested_language, actual_language, and fallback_used flags. Never silently swaps languages unless fallback_language is specified.
| Name | Required | Description | Default |
|---|---|---|---|
| language | No | Desired caption language code (e.g. 'en', 'hi', 'es') | en |
| video_id | Yes | 11-character YouTube video ID or full YouTube URL | |
| translate_to | No | Optional target language code to translate captions into (e.g. 'es', 'fr', 'de') | |
| fallback_language | No | Language code to use ONLY IF the requested language is completely unavailable (set to null/None to disable fallback) | en |
| include_timestamps | No | If true, returns structured segments with start/end timecodes and deep links. If false, returns clean text only. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the behavioral disclosure burden. It discloses the returned provenance flags (requested_language, actual_language, fallback_used) and makes an explicit behavioral guarantee: 'Never silently swaps languages unless fallback_language is specified.' This meaningfully informs the agent about how language selection behaves.
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 concise sentences with no filler. The most important information, what the tool extracts and returns, is front-loaded, followed by a useful behavioral guarantee.
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 covers the core behavior, output provenance flags, and language fallback semantics. It is reasonably complete given the detailed input schema and an output schema; it does not cover every edge case like missing captions, but it provides enough for an agent to select and call 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 description coverage is 100%, so the baseline is 3. The description adds some value by explaining the fallback language behavior and provenance flags, but it does not substantially elaborate on translate_to or include_timestamps beyond what the schema already states.
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 opens with a specific verb and resource: 'Extract the spoken transcript of a YouTube video.' It also clarifies the output includes timestamped segments and language provenance, which immediately distinguishes this from sibling tools like youtube_search or youtube_video.
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 purpose implies this tool is for retrieving a video's transcript, and the wording 'Extract the spoken transcript' gives reasonable context. However, it does not explicitly state when to prefer this over alternatives such as youtube_find_in_video, nor does it mention exclusions or conditions for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve complete metadata, view statistics, tags, chapters, and caption availability for a specific YouTube video. Use this tool to inspect a video's table of contents (chapters) and determine if spoken transcripts are available.
| Name | Required | Description | Default |
|---|---|---|---|
| video_id | Yes | 11-character YouTube video ID or full YouTube URL |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the behavioral burden. It communicates a read-only inspection operation through 'Retrieve' and 'inspect', and clarifies that it only determines transcript availability rather than returning transcript text. It does not discuss rate limits or error behavior, but these are less critical for a single-parameter read tool.
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?
Two sentences, front-loaded with the primary verb and resource, followed by a direct usage note. No filler or repetition of schema details.
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 one-parameter read-only tool with an output schema present, the description fully covers what it does and when to use it. The only minor gap is not naming the transcript alternative, but the phrasing 'determine if spoken transcripts are available' adequately signals that boundary.
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 already documents video_id with type and format ('11-character YouTube video ID or full YouTube URL') at 100% coverage. The description adds no parameter-specific meaning beyond that, so the baseline of 3 applies.
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?
States a specific action (retrieve) on a specific resource (metadata for a specific YouTube video) and enumerates the data categories returned (statistics, tags, chapters, caption availability). This clearly separates it from sibling tools like youtube_search and youtube_transcript, which address different tasks.
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?
Provides explicit use context: 'Use this tool to inspect... chapters and determine if spoken transcripts are available.' However, it does not mention alternatives or exclusion conditions, such as using youtube_transcript for actual transcript content.
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.0youtube_find_in_videoyoutube_researchyoutube_searchyoutube_transcriptyoutube_videoScored across 5 tools
The tools mostly target distinct actions: metadata retrieval, search, transcript extraction, pinpointing content, and autonomous research. The only potential confusion is between youtube_search (finding videos) and youtube_research (which also discovers videos), but the descriptions clarify that youtube_research is a higher-level aggregation tool that subsumes search and transcript extraction.
All tools share the 'youtube_' prefix, which is consistent, but the suffixes mix nouns (video, transcript, research) with verbs (search, find_in_video). This is not a strict verb_noun pattern like the calibration example. The inconsistency is minor but noticeable; a more uniform pattern like youtube_get_video, youtube_search_videos, etc., would improve coherence.
With 5 tools, the count is well within the ideal 3-15 range. Each tool serves a distinct purpose in the research workflow (discovery, metadata, transcript, semantic search, aggregation), and none feels redundant. The number is appropriate for the server's stated purpose.
The tool surface covers the core research lifecycle: search, inspect (metadata), extract (transcript), locate (find_in_video), and synthesize (research). Minor gaps exist, such as no tool for channel-specific queries or playlist retrieval, but these are not essential for the primary research workflow. The inclusion of caption availability checks and language provenance shows attention to detail.
YouTube transcripts, search, channel/playlist listings and upload tracking for AI agents.
YouTube data for AI agents: channels, videos, transcripts, comments, search. Video research.
YouTube transcripts, search, channels, playlists and bulk transcript jobs for AI agents. 14 tools.
YouTube transcripts, search, channel browsing, and playlists for AI agents via MCP.
