Loading ToolBench
Three tools with minimal documentation and no output schemas. Tool names are acceptable (search, play, pause) but descriptions are extremely brief (10-20 chars, well below the 50-200 char LLM-optimized baseline). The 'search' tool lacks error handling for empty results (accesses [0] without bounds checking). Parameters have type hints but no descriptions in the schema. No pagination, no structured output documentation, no error guidance. The server exposes Spotify credentials as hardcoded strings in the source, violating secret injection patterns.
Pause a song on Spotify
Play a song on Spotify
Search for a song on Spotify
Credentials hardcoded in source code (SPOTIPY_CLIENT_ID, SPOTIPY_CLIENT_SECRET). Violates secret-injection pattern, secrets must never appear in tool parameters or source. Use environment variables or vault.
Tool descriptions are 10-20 characters (e.g., 'Search for a song on Spotify'). Baseline for LLM-optimized descriptions is 50-200 chars. Descriptions lack WHEN to use, WHAT it returns, and any prerequisites. LLMs cannot reliably select these tools.
No output schemas documented. LLMs cannot plan downstream calls or extract required data. 'search' returns a URI string; 'play' and 'pause' return generic strings. Structured output with typed fields is required.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 37 | 2026-07-28+ | v2 |
'search' tool accesses results['tracks']['items'][0]['uri'] without bounds checking. If no results found, IndexError crashes the tool. No error guidance for LLM recovery (e.g., 'Try a different search term').
Parameter 'song_name' in search and 'song_uri' in play lack descriptions in the schema. LLMs cannot infer what format song_uri expects (Spotify URI format is opaque). Add parameter descriptions explaining format and constraints.