Loading ToolBench
MCP server that provides YouTube search functionality for videos and channels with structured JSON responses
The server defines 2 tools with clear, action-oriented names and reasonable descriptions. Both tools have complete input schemas with proper typing and parameter descriptions. However, output schemas are not explicitly documented in the code, error handling lacks recovery guidance, and no tool annotations (readOnlyHint/destructiveHint) are present. The implementation shows solid naming discipline ('search_youtube_videos', 'search_youtube_channels') and parameter validation (enums for 'order', bounds on 'max_results'), but falls short of A-grade rigor in output documentation and error guidance.
Search YouTube channels and return structured data with channel details including title, subscribers, video count, total views, created date, URL, description, and thumbnail
Search YouTube videos and return structured data with video details including title, channel, views, likes, published date, URL, description, and thumbnail
Output schemas are not documented in source. LLMs cannot plan downstream operations or extract required fields without explicit documentation of the response structure (fields, types, required properties).
Error messages lack recovery guidance. Errors return generic messages like 'YouTube API error: ...' and 'Unexpected error: ...' without actionable next steps. When the API key is unconfigured, the error says 'Please set YOUTUBE_API_KEY in your .env file' (good for setup, not for runtime). For HTTP errors, LLMs receive no guidance on retry strategy or alternative approaches.
No tool annotations. Neither tool declares readOnlyHint (both are read-only, safe for agents to call freely) or idempotentHint (both are idempotent, calling with the same query returns the same results). Without these hints, agents may waste reasoning cycles or apply unnecessary caution.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | B | 78 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 0 | - | v1 |
Parameter descriptions lack format/constraint details. The 'order' enum is declared and described, but 'max_results' lacks explicit min/max bounds in the description text (code implies default 5, max 50, but this is not visible in the schema description for the LLM). The 'query' parameter provides no guidance on minimum length, special characters, or what constitutes a valid search string.
Responses strip truncated descriptions. The code truncates description fields to 200 chars + '...' without documenting this in the tool description. LLMs may expect full descriptions or attempt to request more data, causing confusion about available fields.