Loading ToolBench
Control Spotify from Claude, Cursor, or any MCP client. 100+ tools for playback, playlists, discovery, and curation.
Spotify MCP has decent naming conventions (all tools start with 'spotify_' verb_noun pattern) and comprehensive parameter schemas with types and descriptions. However, there are significant gaps: (1) Output schemas are not documented, the source code shows parameter input schemas but return types are missing or inferred from code; (2) Many descriptions are adequate but some lack context about when to use a tool vs alternatives; (3) No explicit error handling guidance in descriptions; (4) Tool descriptions vary in quality, some detailed (spotify_sync_library at ~180 chars), others minimal (spotify_status at ~65 chars, below the preferred 50-200 char range per arcade baseline). All 11 tools have input schemas visible in the rubric summary, but actual return type documentation is not present in the provided code excerpt, forcing inference. This lands the server in the 'fair to good' range but prevents a higher score due to missing output schema documentation.
Get a comprehensive artist profile including genres, full discography, and related artists.
Map an artist's network of related artists. Depth 2 reveals bridge artists connecting different parts of the network.
Map an artist's full release timeline grouped by year, with career span and release type counts.
Find songs using a natural-language description. Parses quoted titles, "by artist", decade refs, and genre keywords.
Get a summary of your synced library — artist counts, playlist names, and dates. Returns your full artist landscape (compact) so the AI can reason about vibes, genres, and groupings without loading every track.
Output schemas not documented. Source code excerpt does not show return type specifications or structured output definitions for any of the 11 tools. Return types are inferred from implementation (e.g., spotify_status returns formatted string; spotify_sync_library returns sync summary). LLMs cannot plan downstream tool calls or extract structured data without documented return schemas.
Error handling guidance missing. Tool descriptions do not explain how errors are categorized (retryable vs. user-fixable vs. fatal) or what recovery steps the LLM should take. E.g., 'spotify_sync_library' does not explain what happens if a playlist is deleted mid-sync, or if Spotify API rate limits are hit.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 59 | <=2025-11-25 | v2 |
Analyze recent listening patterns: time-of-day, day-of-week, sessions, and repeat plays.
Compare 2-5 playlists side by side: shared tracks, shared artists, unique tracks, and size/duration.
Query your synced library with filters. Returns matching tracks with URIs. All filters are combined with AND logic. All text matching is case-insensitive and supports partial matches.
Check Spotify connection status, profile info, and current playback.
Sync your Spotify library to a local index for AI-powered playlist curation. Fetches all liked songs and tracks from playlists you created (skips followed/saved playlists by others). Run periodically to keep fresh.
Build a genre taste profile with diversity score and niche artist detection from your top artists.
Inconsistent description quality and length. 'spotify_status' (65 chars) is below the 50-200 char arcade baseline for LLM-optimized descriptions. Others like 'spotify_sync_library' (180 chars) and 'spotify_query_library' (multi-line) are better. Inconsistency signals rushed documentation and forces LLMs to infer intent variably.
No documented pagination or result limits. 'spotify_library_stats', 'spotify_artist_network' (depth 2 could expand to thousands of related artists), and 'spotify_query_library' (limit default 200) lack explicit cap guidance. The source does not show whether results are capped or paginated, risking context window exhaustion.
Parameter dependency not documented. 'spotify_query_library' combines multiple filters (artists, playlist_name, added_after, added_before, track_name, album_name, source) with AND logic, but descriptions do not clarify interaction or precedence. E.g., does 'source: all' override artist filter, or combine with it? This ambiguity will cause LLM misuse.
Missing prerequisite hints. 'spotify_artist_timeline' and 'spotify_artist_network' require an 'artist_id' parameter, but descriptions do not guide the LLM on how to obtain it. If the user says 'Show me Taylor Swift's timeline', the LLM must infer that it needs to call 'spotify_find_song' or a search tool first, this is not documented.