Loading ToolBench
MCP server to control Spotify conversationally from Claude, Cursor, and other AI clients
Spotify MCP demonstrates solid definitions with clear, action-oriented tool names and comprehensive parameter schemas. All 11 tools have descriptions (range 75-210 chars, well within the 10-1024 baseline). Most tools have well-typed input schemas with enums for constrained values. However, several issues prevent a higher score: (1) Output schemas are completely undocumented, the descriptions tell users what data is returned conceptually, but there are no visible JSON Schema definitions for return types. (2) Several parameters lack descriptions (e.g., 'device' in devices tool, 'offset' in get_playlist_items). (3) Error handling is mentioned in descriptions but not formally structured, no recovery guidance or error categories visible in code. (4) The 'authenticate' tool exposes OAuth flow details but lacks explicit security notes about token storage. (5) Tools like 'play' and 'queue' could benefit from dependency hints (e.g., 'To get a Spotify URI, use search() first'). The tool composition is generally strong, each tool has one clear responsibility, and the design mirrors the Spotify API well. Parameter naming is excellent (verb_noun convention, specific types like query/uri/device_id). Token/session management is handled server-side, which is correct. Overall, this is a competent, well-structured server that exceeds community averages but falls short of production A-grade due to missing output documentation and incomplete error handling patterns.
Connects the user's Spotify account via OAuth. Opens a browser on this machine for approval and stores tokens locally. Use when other tools report you are not authenticated, or to switch accounts.
action=list shows available Spotify devices; action=transfer moves playback to a device by name or id.
Lists the tracks in one of the user's own or collaborative playlists (Spotify no longer exposes other users' playlist contents). Accepts a playlist id, URI, or URL.
Lists the user's playlists with item counts and URIs.
Saves, removes, or checks items in the user's Spotify library ('liked'). Works with any content URI: tracks, albums, artists (follow), shows, episodes. To save the current song, get its URI from now_playing first.
action=create makes a new playlist (private by default); action=add_items appends track URIs to an existing playlist. Does not delete or remove anything.
Output schemas completely undocumented. No JSON Schema definitions visible for return types of any tool. Users/LLMs cannot know what fields to expect, making downstream tool chaining and field extraction error-prone.
Several parameters lack descriptions. 'device' in devices.transfer, 'offset' in get_playlist_items lack guidance on expected format/range. Parameter descriptions are critical for LLM action selection.
Error handling is implicit in descriptions but lacks formal structure. No visible recovery guidance (e.g., 'If authentication fails, call authenticate() first'). No error categorization (retryable vs. user-fixable vs. fatal).
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 58 | 2026-07-28+ | v2 |
Current track, artist, album, progress, device, and shuffle/repeat state.
Plays music by free-text query (searches and starts the best match) or by Spotify URI. Handles "play some Radiohead", "play the album Kind of Blue", "play my Discover Weekly". Reports what it picked — relay that to the user so they can correct it.
Transport controls for the active playback: pause, resume, next, previous, seek (value = seconds), volume (value = 0-100), shuffle (value = on/off), repeat (value = off/context/track).
action=add queues a track by query or URI; action=list shows what's playing and up next.
Searches the Spotify catalog. Use when the user wants options to choose from; for a direct 'play X' request, prefer the play tool. Results include URIs usable with play, queue, playlists, and library. Max 10 results per type (API limit).
Missing dependency hints in descriptions. 'play' and 'queue' tools accept Spotify URIs but don't explicitly guide the LLM to use search() when no URI is available. This forces agents to discover the two-step pattern.
Result limits not explicitly documented in descriptions. search() caps at 10 results per type (API limit), but the description does not state this constraint. Users/LLMs may expect unlimited results.