Loading ToolBench
A Model Context Protocol server for Spotify integration
Spotify controller has solid schema coverage (all 13 tools have Zod-validated input schemas with type definitions and descriptions) and clear naming conventions (verb_noun pattern: playMusic, pausePlayback, skipToNext, etc.). However, tool descriptions are brief (avg ~60 chars, well below the 194-char baseline for A+ tools) and lack context about when to use each tool or what happens on error. Parameter descriptions are present but minimal. Output schemas are not documented, callers cannot predict response structure. Error handling is basic (returns isError flag but no recovery guidance). No tool annotations (readOnlyHint/destructiveHint) despite clear read/write distinction. Composition is good: tools are single-responsibility and chainable (e.g., searchSpotify → playMusic). Security: credentials handled server-side via handleSpotifyRequest wrapper, not exposed as parameters.
Adds a track, album, artist or playlist to the playback queue
Add tracks to a Spotify playlist
Create a new playlist on Spotify
Get a list of the current user's playlists on Spotify
Get information about the currently playing track on Spotify
Get a list of tracks in a Spotify playlist
Get a list of recently played tracks on Spotify
Tool descriptions are too brief (avg ~50 chars vs. 194-char baseline). Most lack context about when to use the tool, what it returns, or prerequisites. E.g., 'Pause Spotify playback on the active device' does not explain what 'active device' means or how to specify a device.
Output schemas are not documented. Callers cannot predict response structure (e.g., what fields does getNowPlaying return? Is it a track object or a string?). This forces LLMs to guess and wastes tokens on trial-and-error.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 64 | 2026-07-28+ | v2 |
Pause Spotify playback on the active device
Start playing a Spotify track, album, artist, or playlist
Resume Spotify playback on the active device
Search for tracks, albums, artists, or playlists on Spotify
Skip to the next track in the current Spotify playback queue
Skip to the previous track in the current Spotify playback queue
No tool annotations (readOnlyHint/destructiveHint/idempotentHint). The schema clearly marks tools as READ_ONLY or WRITE, but this is not exposed in the MCP tool definition. LLMs cannot distinguish safe reads from destructive writes without explicit hints.
Error handling returns isError flag but no recovery guidance. E.g., playMusic returns 'Error: Must provide either a URI or both a type and ID', good, but other tools (pausePlayback, skipToNext) do not validate inputs and will fail silently with Spotify API errors. No guidance on retryability or next steps.
Parameter descriptions lack format/constraint details. E.g., 'limit' params say 'Maximum number of results to return (10-50)' but do not specify what happens if you pass 0, 100, or -1. 'deviceId' is optional but no guidance on what 'active device' means or how to discover device IDs.