Loading ToolBench
FastMCP Server provider for Music Assistant that exposes the library, queue, playback, players, and metadata controllers as a Model Context Protocol server, accessible to Claude Code, Codex, and other MCP-aware LLM clients.
The server exposes 3 tools with clear names and READ_ONLY/WRITE risk profiles. Tool names follow verb-noun convention (search_, get_, call_), and all have descriptions. However, descriptions are minimal (15-62 chars), underdocumented parameter constraints, and output schemas are not explicitly documented in the visible code. The tooling is functional for Music Assistant command wrapping but lacks the LLM-optimization guidance expected in A/B-tier servers. Parameter descriptions exist but are sparse; no enum constraints, validation rules, or chaining metadata visible. Error handling and recovery guidance are absent from descriptions.
Execute a Music Assistant command with the provided parameters
Get the detailed schema for a specific Music Assistant command
Search available Music Assistant commands by query
Minimal tool descriptions (15 - 62 chars). Rubric baseline is 194 chars avg; all three tools are 40 - 66% below baseline. Descriptions lack WHEN to use, WHAT is returned, and dependency hints required for LLM selection.
Parameter schemas present but lack descriptions beyond single-word labels ('Search query for discovering commands' for search_tools.query is thin; no format, enum, range, or validation rules visible). Rubric baseline: 100% of A+ params have descriptions; these are 1 - 2 sentence fragments.
Output schemas not documented in visible code. Rubric requires documenting output schema (field names, types, examples) so LLMs can plan downstream calls and extract data correctly. No visible return type documentation for any tool.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 54 | 2026-07-28+ | v2 |
call_tool accepts an 'arguments' object (type: object) with no schema, constraints, or description of expected structure. This violates constrained-input pattern: free-form objects invite hallucinated/invalid values. LLM has no guidance on what keys/types arguments must contain.
No error handling or recovery guidance in tool descriptions. Rubric requires error responses to tell the LLM what to do next ('Try search_tools() first'). No visible error classification (retryable, user-fixable, fatal) or recovery patterns.
call_tool is marked WRITE but no confirmation/dry-run pattern documented. Rubric requires irreversible operations to support confirmation step. No visible guidance on how to safely execute destructive commands.
No documented pagination, limits, or response shaping. If search_tools returns hundreds of commands, no guidance on limits or how to handle large result sets. Rubric requires capping results at 20 - 50 and offering pagination.
call_tool's 'command' parameter expects 'canonical ma_api:* command identifier' but no enum, examples, or validation rules visible. LLM has no guidance on valid command format beyond a comment. No discovery link to get_tool_schema.