MCP server for controlling Sushi audio workstation via gRPC
Server has 8 tools with basic schemas and descriptions, but significant gaps limit production readiness. All tools have descriptions (10-50 chars, mostly short), and input schemas are present with type definitions. However, descriptions lack depth, most are single-sentence and do not explain WHEN to use the tool, prerequisites, or dependencies. Parameter descriptions are minimal (e.g., 'IP address of the Sushi server' without format guidance). Output schemas are not documented, LLMs cannot predict response structure. Error handling is absent; tools return raw strings without guidance on recovery. No enum constraints on mode parameters (set_playing_mode accepts free-form 'mode' string). Tool composition is reasonable (single responsibility), but missing chaining IDs in responses (e.g., get_all_tracks returns track IDs but no context for downstream processor lookups). Security: global state (sushi_ip, sushi_port) is mutable and not validated; no rate limiting or permission checks.
Get information about all tracks in Sushi.
Get all parameters for a processor.
Get information about the Sushi system.
Get all processors on a track.
Get information about the Sushi transport state.
Set the playing mode of Sushi.
Set the IP address and port of the Sushi server.
Output schemas not documented. LLMs cannot predict response structure (e.g., get_sushi_info returns dict with version, build_options, etc., but this is not declared in tool definition). Agents cannot plan downstream calls or extract fields reliably.
set_playing_mode accepts free-form 'mode' string parameter without enum constraint. Description says '(STOPPED, PLAYING, RECORDING)' but this is not enforced in schema. LLMs may hallucinate invalid values like 'PAUSED' or 'RESUME'.
Descriptions are too short (10-50 chars) and lack context. None explain WHEN to use the tool vs. similar tools, prerequisites, or dependencies. E.g., 'Get information about the Sushi system' does not say whether this is a discovery tool or a status check, or when to call it before other operations.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 49 | <=2025-11-25 | v2 |
Set the tempo of Sushi.
No error handling or recovery guidance. Tools return raw strings like 'Failed to connect to Sushi server at {ip}:{port}: {str(e)}' without actionable next steps. LLMs cannot determine if error is retryable, user-fixable, or fatal.
Global mutable state (sushi_ip, sushi_port) is not validated or rate-limited. No permission checks on destructive operations (set_tempo, set_playing_mode). Agents can modify Sushi state without authorization or audit trail.