Loading ToolBench
ListenBrainz MCP server providing access to open music listening data from MetaBrainz/MusicBrainz. Enables querying sitewide top artists, user listening history, now-playing tracks, and user top artists.
Four tools with complete schemas and reasonable descriptions. Naming follows verb_noun convention (top_artists, user_listens, now_playing, user_top_artists). Descriptions are 100-180 chars, within baseline range (p10=34, p90=392). All parameters have type definitions and descriptions. However, parameter descriptions lack constraint details (e.g., 'range' accepts only 4 values but no enum; 'count' has max 100 but not stated as a constraint in description text). Output schemas are not documented, LLMs cannot predict response structure. Error handling returns generic error objects without recovery guidance. No tool annotations (readOnlyHint, idempotentHint). Parameter descriptions mention defaults but do not use formal enum constraints.
What a ListenBrainz user is listening to right now (the currently-playing track, if any). Open music listening data. Keyless for public profiles.
ListenBrainz sitewide top artists (open music listening data, MetaBrainz/MusicBrainz-linked). Most-listened artists across all users for a time range. Keyless.
A ListenBrainz user's recent listens (track scrobbles), newest first. Open music listening data, MusicBrainz-linked. Keyless for public profiles.
A ListenBrainz user's top (most-listened) artists for a time range. Open music listening data, MusicBrainz-linked. Keyless for public profiles. Stats may be unavailable if not yet computed.
Output schemas not documented. LLMs cannot predict response structure (e.g., does top_artists return {artists: [{name, mbid, listens}]} or {data: {artists: [...]}}?). This forces agents to guess field names and risks extraction errors.
Parameter 'range' accepts only 4 values (week, month, year, all_time) but is defined as free-form string with no enum constraint. LLMs may hallucinate invalid values like 'fortnight' or 'quarterly'.
Parameter descriptions mention constraints (e.g., 'max 100') but do not use formal JSON Schema minItems/maxItems or pattern fields. LLMs read descriptions, not schema metadata, constraints must be in description text.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 57 | 2026-07-28+ | v2 |
Error responses return generic {error: string} without recovery guidance. E.g., 'ListenBrainz: 404' tells LLM nothing about whether to retry, call a different tool, or ask the user.
No tool annotations (readOnlyHint, idempotentHint). All four tools are read-only and idempotent, but this is not declared in the tool definition. Agents cannot infer safety properties.