YouTube MCP server has foundational tool definitions but significant quality gaps. All 4 tools are explicitly registered with names, descriptions, and input schemas visible in src/index.ts. However, descriptions are minimal (10-60 chars), parameter annotations lack detail or are missing, output schemas are completely undocumented, and error handling provides no recovery guidance. Naming follows verb_noun convention (get_, list_, convert_) but lacks specificity around what data structures and fields are returned. No tool annotations (readOnlyHint, idempotentHint, destructiveHint) despite all tools being READ_ONLY. Parameter descriptions fail to specify formats, constraints, or expected behavior, e.g., 'Language code (e.g., en, fr)' is too vague; should specify BCP-47 format, how to discover valid codes, and fallback behavior. The 'options' object in convert_to_markdown has nested properties (include_chapters, search_term) but lacks descriptions entirely for the nested fields, violating parameter documentation rules. No indication of output structure, pagination support, or field chaining across tools.
Convert video captions to markdown
Get captions for a video in specified language
Get video metadata including available captions, chapters, and languages
List available markdown templates
Output schemas completely undocumented for all tools. LLMs cannot determine what fields will be returned, forcing blind tool calls and errors. Tool responses are returned as JSON text without field-level documentation.
Nested parameter 'options' in convert_to_markdown has properties (include_chapters, search_term) with zero description. Violates rule: 'Every parameter needs a description.' Sub-properties must be described or promoted to top-level parameters.
Parameter 'language' in get_captions and convert_to_markdown lacks format specification and constraint documentation. Description 'Language code (e.g., en, fr)' invites hallucination, should specify BCP-47 format, max length, valid values, or point to list_templates/discovery tool.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 44 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 40 | - | v1 |
Tool descriptions are too short (35-42 chars for most) and generic. None answer WHEN to use the tool, what it returns, or dependencies. Descriptions lack actionable context for LLM selection.
Error handling returns generic McpError with codes but no recovery guidance. Per pattern:recovery-guide, errors must tell LLM what to do next. E.g., 'URL is required and must be a string' gives no hint that the user should provide a valid YouTube URL or that search tools exist.
No tool annotations declared (readOnlyHint, idempotentHint, destructiveHint) despite metadata in rubric noting all tools are READ_ONLY. Per current MCP spec, tools should declare these hints to optimize agent planning.
Parameter 'url' is accepted as free-form string with no validation hints. Description says 'YouTube video URL' but no format pattern, error message examples, or URL validation rules. LLMs may pass non-YouTube URLs, invalid formats, or hallucinated URLs. Should specify format or provide regex pattern in description.
No pagination support or result limits documented. If get_video_info returns 100+ chapters or get_captions returns 1000+ caption entries, response could bloat context window.