Loading ToolBench
Self-hostable MCP v2 server for Spotify catalog, library, playlists, playback, and listening activity.
Strong tool naming (verb_noun pattern), comprehensive descriptions (avg 180 chars), and well-structured input schemas with type definitions. Tool annotations present for all 9 tools. However, parameter descriptions are sparse or missing in several tools, output schemas are not explicitly documented in the code, and error handling guidance is absent. Composition is excellent, tools are single-responsibility and chain well via ID references. Security posture is good (no secrets in params, auth middleware present). Naming clarity is high; all tools start with action verbs and distinguish operations clearly (search_catalog vs get_item vs player_status vs player_control).
Fetch 1-25 heterogeneous Spotify items by ID, URI, or web URL. Optionally include natural child collections such as album tracks or show episodes in the same call.
Run 1-20 ordered save, remove, follow, or unfollow actions through Spotify's generic library endpoint. Each idempotent action accepts up to 40 typed Spotify references.
Bundle saved tracks, albums, shows, episodes, or audiobooks; followed artists; and heterogeneous library membership checks of up to 40 Spotify URIs.
Fetch recently played tracks and top tracks or artists across short-, medium-, and long-term ranges. Spotify does not expose podcast listening history here.
Execute 1-20 explicitly ordered playback actions in one call, including transfer, play, pause, navigation, seek, repeat, volume, shuffle, and queue operations.
Parameter descriptions incomplete. Input schemas define 'queries', 'types', 'ids', 'expansions', 'actions', 'uris' but lack descriptions in the visible schema. LLMs cannot infer parameter semantics from names alone (e.g., does 'expansions' mean child tracks, metadata, or both?).
Output schemas not documented in source code. Tool descriptions state what is returned (e.g., 'Spotify paging objects', 'structured warnings') but no explicit JSON Schema for responses. Agents cannot plan downstream calls without knowing response structure.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | B | 79 | 2026-07-28+ | v2 |
Fetch any combination of current playback, available devices, and the queue in parallel. Returns null current playback naturally when nothing is active.
Execute 1-20 ordered playlist creates or mutations. Later actions may reference a playlist created earlier in the same call; item actions mirror Spotify's 100-URI cap.
List the current user's playlists or fetch up to 20 referenced playlists. Playlist item contents are optional and follow Spotify's owner/collaborator access rule.
Search one or more Spotify catalog types in parallel. Returns native type-grouped Spotify paging objects, bounded by Spotify's current limit of 10 results per page.
No error handling guidance in tool descriptions. Destructive tools (playlist_modify, library_modify) mention 'partial success' and 'structured warnings' but do not explain how to interpret failures or what recovery steps are available.
Batch operation semantics unclear. Tools like player_control accept 'ordered playback actions' and playlist_modify accept 'ordered playlist creates or mutations', but descriptions do not specify atomicity, rollback behavior, or per-action error reporting.
Pagination not explicitly documented. search_catalog mentions 'bounded by Spotify's current limit of 10 results per page' but does not describe how to request subsequent pages (offset, cursor, limit params).