MCP server providing YouTube search and channel lookup tools via multiple transports (SSE and Stdio)
The server defines 2 tools with basic functionality but significant quality gaps. Both tools have descriptions and schema definitions, but descriptions are minimal and parameter documentation is incomplete. The 'searchVideo' tool (mcp-remote) has an optional parameter with minimal context; the 'get-youtube-channel' tool (mcp-stdio) has a constrained parameter but lacks context about what the tool does or when to use it. Neither tool documents output schemas, limiting LLM understanding of what data will be returned. No error handling guidance is present. The server split YouTube search functionality across two transport mechanisms (HTTP+SSE vs STDIO), which violates composition patterns.
Get YouTube Channel
Search for a video on YouTube
Minimal tool descriptions lack WHAT, WHEN, and output context. 'Search for a video on YouTube' and 'Get YouTube Channel' do not explain return structure, pagination, or when to use each tool vs. the other.
No output schema documentation. Both tools return formatted text with embedded metadata (title, description, thumbnail, channel, etc.), but LLMs cannot plan downstream calls or extract structured data without a documented output schema.
Parameter descriptions are generic or missing context. 'q' in searchVideo is optional but no guidance on behavior when omitted. 'query' in get-youtube-channel constrains length (1-100 chars) but the description does not mention this is a handle/name lookup rather than free-text search.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 40 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 37 | - | v1 |
No error handling guidance. When the API returns no results or fails, the tools return a text message ('No results found') but do not guide the LLM on recovery actions (e.g., 'Try a simpler query' or 'Check your API key').
Identical functionality split across two transport mechanisms (HTTP+SSE in mcp-remote, STDIO in mcp-stdio). LLMs will conflate 'searchVideo' and 'get-youtube-channel' as two ways to search YouTube, when one searches videos and the other searches channels. Naming does not make this distinction clear enough.
Parameter 'q' in searchVideo is optional but marked with z.optional() without a description of fallback behavior. If omitted, does the tool return an error, all videos, or a list of trending videos? This ambiguity will cause LLM failures.
Tool names do not distinguish search scope. 'searchVideo' searches for videos; 'get-youtube-channel' searches for channels. A clearer naming pattern would be 'search_youtube_videos' and 'search_youtube_channels' to make the distinction obvious at a glance.
Results capped at hardcoded 5 and 5 respectively but this limit is not documented in tool descriptions. LLMs may expect more results and not understand why pagination is needed.