Loading ToolBench
MCP server that lets AI drop a playable music player (Meting-compatible sources) right into the chat — search, single tracks, playlists, synced lyrics.
Three tools with complete schemas, strong descriptions, and clear action verbs. All parameters are typed and described. Tool names follow verb_noun pattern (search_song, play_song, play_playlist). Descriptions are 150-250 chars, well above the 10-char minimum and within the 194-char production baseline. Parameters include enums for musicServer, numeric bounds for limit/startIndex. Output schemas are not explicitly documented in the source, which is a notable gap. Error handling and recovery guidance are absent from descriptions. No tool annotations (readOnlyHint) visible despite all being READ_ONLY operations.
Render a playable music player in the chat for a whole platform playlist (with queue, prev/next). Use when the user shares a playlist id or asks for continuous music. Requires the platform playlist id (the number in the playlist URL).
Render a playable music player in the chat for one song. Use when the user asks to play / listen to a song, or when sharing a track fits the moment (celebration, mood, recommendation). Requires the platform songId — if you don't know it, call search_song first. The player shows cover art, progress, and synced lyrics; the user presses play.
Search a music platform by keyword (song title, artist, or both) and get candidate tracks with their ids. ALWAYS use this first when you don't know the exact platform song id — never invent ids. Then call play_song with the chosen songId.
Output schemas not documented. Tool descriptions state what is returned (e.g., 'candidate tracks with their ids', 'playable music player') but do not specify the JSON structure, field names, or types. LLMs cannot plan downstream calls or extract data reliably without knowing response shape.
Tool annotations missing. All three tools are READ_ONLY (no state mutation), but the source shows no readOnlyHint or destructiveHint annotations in the tool definitions. This prevents clients from optimizing caching, retry logic, or safety checks.
No error recovery guidance in descriptions. search_song says 'ALWAYS use this first when you don't know the exact platform song id' but does not explain what to do if search returns no results or if the user's platform preference is unavailable. play_song requires a songId but does not guide the LLM on what to do if the ID is invalid.
Inferred effective spec: 2026-07-28+.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 69 | 2026-07-28+ | v2 |
Parameter musicServer has enum values but no guidance on default behavior. Description says 'netease (default)' but does not explain when to use other platforms or how to detect the user's preference. This forces the LLM to guess.
search_song limit parameter lacks guidance on result quality vs. quantity tradeoff. Default is 8, max is 20, but the description does not explain when to request more results or how the ranking works. LLMs may request max results unnecessarily, wasting tokens.