Loading ToolBench
网易云音乐 MCP Server - A Model Context Protocol server for NetEase Cloud Music integration
Cloud Music MCP exhibits significant quality gaps across definition, schema, and error handling. While all 12 tools are present and registered via FastMCP's @mcp.tool decorator, the vast majority lack any input parameter schema definition, descriptions rely on external prompt files (visibility unclear), and output handling is unstructured text concatenation rather than documented typed responses. The server targets a music API domain but fails to meet baseline standards for production MCP tools.
Add songs to a playlist
Get album details with song list
Get artist details and top songs
Create a new playlist
Get daily recommended songs
Login via QR code scanning
Get user's playlists
Tool descriptions loaded from external prompt files (via load_prompt()). Descriptions not visible in source code, cannot verify they meet length, clarity, or actionability standards. If prompt files are missing or contain generic text, descriptions fail the critical check.
Input schemas missing or incomplete for 10 of 12 tools. Tools like cloud_music_status, cloud_music_login, cloud_music_get_daily_recommend, cloud_music_my_playlists have empty input schemas ({}), violating the requirement that every tool with variable input must declare parameter types and descriptions.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 47 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 36 | - | v1 |
Get user's subscribed artists or albums
Play a song or playlist via URL scheme or web browser
Get playlist details with complete song list
Search for songs, albums, artists, or playlists
Check current login status and retrieve user information
Output responses are unstructured formatted text strings (e.g., 'text += f"{i}. {song[name]} ...'). No documented output schema; LLMs cannot infer structure or extract programmatically. Responses should be JSON-serialized objects with typed fields (e.g., {items: [{id, name, artist}], total: int}).
Parameter descriptions incomplete. cloud_music_search's 'keyword' param lacks usage guidance ('what keywords does the API accept? any length limits?'). cloud_music_add_to_playlist's 'track_ids' is array with no element type hint (int vs string?), no validation rules, no example format.
No error recovery guidance. When a tool returns 'error', the response is a bare string (e.g., 'get_daily_recommendations error'). LLM cannot infer if the error is retryable, user-fixable, or requires a different tool. No pattern: error-classification or recovery-guide implemented.
Destructive operations (cloud_music_create_playlist, cloud_music_add_to_playlist) lack confirmation or dry-run capability. Agent could accidentally create many playlists or corrupt state without user approval.
No permission checks or audit trails. Tools like cloud_music_login, cloud_music_create_playlist, cloud_music_play execute without verifying user authority or logging who called what. No pattern: permission-gate or audit-trail.
Hardcoded result limits (e.g., cloud_music_get_daily_recommend returns only first 10 songs) with no pagination or offset parameter. LLM cannot fetch remaining items or control batch size. Violates paginated-result pattern.
Tool composition gaps. Users say 'play this song', but cloud_music_play requires separate ID lookup and type routing. No 'play_song_by_name' or intelligent resolution. Violates chat-data-model principle (agents expect to work with names, not opaque IDs).