Composite MCP server - VirtualDJ + Plex + more (cross-server workflows)
All 4 tools have descriptions and basic schemas, but critical gaps undermine quality. Tool names lack clear verb-noun structure (plex_to_deck, plex_playlist_to_automix are compound actions). Parameter descriptions are present but generic, no constraints, ranges, or format guidance. Output schemas are completely undocumented; callers cannot predict response structure. Error handling is minimal (generic 'success': false). The code snippet shows incomplete implementation (line ends mid-function with 'shu' typo), suggesting unfinished work. Cross-server dependencies (importing from virtualdj_mcp, plex_mcp) are hardcoded and fragile.
Search Plex for multiple tracks and load them to consecutive decks. Perfect for quick setup: provide 8 search queries, get 8 decks loaded!
Load a Plex playlist into VirtualDJ's automix queue. Cross-server workflow: 1. Get playlist from Plex 2. Extract all track file paths 3. Load tracks to VirtualDJ automix queue
Search Plex library and load result directly to VirtualDJ deck. This is a CROSS-SERVER workflow: 1. Search Plex for media matching query 2. Get file path from Plex 3. Load track to VirtualDJ deck
Save a VirtualDJ recording to Plex library. Cross-server workflow: 1. Get recording file from VirtualDJ 2. Copy/move to Plex music library path 3. Trigger Plex library scan
Output schemas completely undocumented. Tools return dicts with 'success', 'error', and domain-specific fields, but LLMs cannot predict structure or plan downstream calls. No field descriptions, types, or examples.
Parameter descriptions lack constraints. 'deck_id' (1-8) and 'limit' (default 50) have no min/max bounds stated. 'search_type' accepts 'track|album|artist' but no enum constraint. LLMs may pass invalid values.
Tool names are compound actions (plex_to_deck, plex_playlist_to_automix). Names should follow verb_noun pattern (load_plex_track_to_deck, queue_plex_playlist_to_automix) for clarity.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 48 | 2026-07-28+ | v2 |
Error handling is generic. All failures return {'success': False, 'error': str(e)}. No guidance on retry, user action, or recovery. LLMs cannot determine if error is transient or fatal.
Source code incomplete. Line ends with 'shu' (typo for 'shuffle'). Implementation is unfinished, suggesting beta/broken state. Cannot fully assess actual behavior.