Loading ToolBench
MCP server that provides tools for searching and retrieving information about YouTube videos and channels, with interactive UI components for rendering video cards and channel profiles.
The YouTube MCP server demonstrates reasonable tool structure with three clearly named, read-only tools. All tools have descriptions and input schemas using Zod. However, critical gaps exist: (1) Output schemas are NOT documented, responses return JSON as untyped strings, forcing LLMs to parse without knowing expected fields; (2) Parameter descriptions are minimal, 'Channel ID (UC...), handle (@name), or channel name' is helpful but lacks format/constraint details for LLMs to validate input; (3) Error handling is basic, error responses are JSON strings with only 'error' field, lacking recovery guidance per pattern:recovery-guide; (4) No documented response structure, the code shows what JSON fields will be returned (videoId, title, thumbnailBase64, channelId, channelTitle, publishedAt), but this is inferred from code, not explicitly documented for LLMs. The server uses Zod schemas (good baseline), registers tools via registerAppTool and registerTool, and all tool names follow verb_noun convention (get-video, get-channel, get-latest-video). All tools are READ_ONLY with no destructive operations. Avg tool score: 62.
Gets information about a YouTube channel including avatar, description, subscriber count, and video count.
Gets the most recent video from a YouTube channel
Searches for a video on YouTube and returns its information.
Output schemas not documented in tool definitions. All three tools return JSON responses, but the expected fields and types are inferred from code implementation, not declared. LLMs cannot reliably plan multi-tool chains without explicit response schemas.
Error responses lack recovery guidance. When a video/channel is not found, the tool returns {error: '...'} with no suggestion of next steps (e.g., 'Try search with a different query' or 'Did you mean: ...?'). Per pattern:recovery-guide, errors should guide the agent toward resolution.
Parameter format constraints underdocumented. The 'channelIdentifier' param accepts 'Channel ID (UC...), handle (@name), or channel name' but lacks clarity on exact matching, substring search, case sensitivity, or precedence rules. LLMs cannot reliably construct valid input without formal constraints.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-21 | D | 57 | 2026-07-28+ | v2 |
| 2026-03-09 | D | 58 | - | v1 |
No pagination or result limits documented. If a search returns many results, the tool does not appear to offer pagination/limit params. The code shows only single result return, but for discovery use cases, limiting and paginating large result sets is critical (pattern:paginated-result).
Minimal parameter descriptions. While descriptions exist, they are bare minimum (e.g., 'Search query for the video'). Per pattern:tool-description baseline (avg 72 chars), descriptions should include context, constraints, and examples of valid input.