Loading ToolBench
A Model Context Protocol server that allows playing songs on YouTube Music via the YouTube API
Single tool with basic structure but significant gaps in description depth, error recovery guidance, and output schema documentation. Tool naming is verb-action appropriate ('play_song'), but the description is extremely sparse (26 characters) and lacks critical details like prerequisites, expected format, and what constitutes success/failure. Input schema is present with correct typing and descriptions, but output schema is entirely undocumented. Error handling exists but provides no recovery guidance. No tool annotations. The implementation demonstrates basic competency but falls well short of production quality standards.
Play a song on Youtube Music
Tool description is critically sparse (26 chars: 'Play a song on Youtube Music'). Provides no context on WHEN to use this tool, prerequisites (YouTube Music account, browser setup, API key), expected return format, or error modes. LLMs cannot determine tool selection criteria without this detail.
No output schema documented. Callers cannot determine what fields to expect or plan downstream operations. The response returns a text message but LLMs need to know if this is success/failure, what metadata is included, what the URL format is, etc.
Error handling lacks recovery guidance. Code throws McpError for various failure modes (search fails, script execution fails) but does not explain what the LLM should try next. E.g., 'Error opening song in Chrome' gives no guidance on whether to retry, try a different approach, or ask the user.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 46 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 27 | - | v1 |
artist_name parameter is optional but the interaction between song_name and artist_name is underdocumented. No guidance on when to provide both vs. just song_name, how the search query is constructed, or what happens if multiple results match. Parameter descriptions ("Name of the song to play", "Name of the artist") are generic and lack usage context.
Implementation hardcodes macOS/Chrome-specific behavior (osascript to open Chrome). No documentation of platform prerequisites, no graceful degradation for other OS/browsers, no fallback if Chrome is not installed. This makes the tool effectively non-portable and breaks silently on Linux/Windows.
No support for idempotency. If the LLM retries play_song with identical parameters due to an ambiguous error, it will search for the same song again and may open it multiple times. No idempotent operation pattern or request deduplication.
Search results are logged to stderr and capped at 5 (maxResults hardcoded in axios config), but the tool description does not mention this limit. If multiple songs have the same title, the LLM has no control over which one plays, it always picks the first result. No way to refine search or see alternatives.
API key (YOUTUBE_API_KEY) is correctly injected via environment variable (not a parameter), which is good. However, no documentation in tool descriptions mentions that an API key is required or what permissions it needs.