Loading ToolBench
A comprehensive MCP server for Music Assistant — playback, library, providers, and (uniquely) user & access management.
23 tools with consistent naming (ma_* prefix, verb-noun pattern). All have descriptions (10-200 chars, mostly 50-150). Input schemas present for all tools with proper type declarations. However, output schemas are completely undocumented, LLMs cannot predict response structure. Error handling is minimal; no recovery guidance or actionable error messages. Parameter descriptions are adequate but lack format constraints (e.g., no enum for 'command' despite fixed set). No tool annotations (readOnlyHint/destructiveHint). Security concern: user creation/update tools expose password parameters directly. Composition is sound, tools are single-purpose and chainable.
One-shot: create a (restricted) user and apply player/source filters. Returns the final user.
Mint a long-lived token (e.g. for the MA mobile app). CONFIRMED (auth/token/create).
Create a user. role one of admin|user|guest. CONFIRMED (auth/user/create).
Disable a user (keeps their settings). CONFIRMED (auth/user/disable).
Enable a user. CONFIRMED (auth/user/enable).
Full record for one user, incl. player_filter / provider_filter. CONFIRMED (auth/user).
No output schemas documented. LLMs cannot predict response structure, forcing them to guess field names for downstream tool calls. This breaks tool chaining and increases hallucination risk.
Password parameters exposed in ma_create_user and ma_update_user. Credentials must never appear as tool parameters, they leak into agent traces and logs. Use server-side secret injection instead.
No enum constraints for fixed-value parameters. 'command' in ma_player_command accepts a free-form string despite only 10 valid values. Enums prevent hallucinated values and are self-documenting.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 66 | 2026-07-28+ | v2 |
Group/sync one or more players under a target player.
List all players/speakers with their current state (playing, volume, group). CONFIRMED (players/all).
List configured music/player providers and their status.
List long-lived tokens / sessions (optionally for one user). CONFIRMED (auth/tokens).
List all Music Assistant users (username, role, enabled). CONFIRMED (auth/users).
What a player's queue is currently playing, incl. track and progress.
Play media (uri, or an item's name) on a player. enqueue: replace|next|add|replace_next. CONFIRMED command (player_queues/play_media).
Send a transport command to a player. command: one of play, pause, play_pause, stop, next, previous, power, volume_up, volume_down, volume_mute.
Search the library/providers. media_types e.g. ['artist','album','track','playlist','radio'].
Music Assistant server info: version, schema, base_url, onboarding state. CONFIRMED.
Restrict a user to a specific set of players (sets player_filter).
Restrict a user to a specific set of music sources (sets provider_filter).
Set a player's volume to an absolute level (0-100).
Trigger a library sync (all providers, or one provider instance_id).
Remove a player from its sync group.
Update a user's role / display name / restrictions / enabled flag. CONFIRMED (auth/user/update).
Summary of every player that is currently playing (name, state, current track).
No tool annotations (readOnlyHint, destructiveHint, idempotentHint). LLMs cannot distinguish safe reads from destructive writes without explicit hints. ma_player_command, ma_create_user, ma_sync_library should be marked destructive.
No error handling guidance. Tools return raw API responses without recovery hints. E.g., 'User not found' should suggest 'Try ma_list_users() to find the correct user_id.' Agents need actionable next steps.