Loading ToolBench
An MCP server that generates musical compositions based on routing directions by analyzing geographic/cultural context and creating styled music with lyrics derived from navigation instructions.
The server defines 2 tools with reasonable naming (verb_noun pattern: find-musical-style, generate-music) and documented schemas. However, descriptions are generic and lack LLM-optimization guidance. Parameter descriptions exist but lack specificity about formats, constraints, and when to use each tool. Output schemas are not documented. Error handling lacks recovery guidance. The tools compose logically (find style → generate music), but lack idempotency and confirmation patterns for the destructive generate-music tool.
Find a musical style based on given routing directions by drawing cultural references from the location.
Generate music based on a musical style card and lyrical directions, with optional route graphics visualization data.
Tool descriptions lack LLM-optimization. 'Find a musical style based on given routing directions by drawing cultural references from the location' (94 chars) is vague about WHEN to use this tool vs alternatives, what it returns, and dependency hints. Should state: 'Call first to generate a StyleCard before calling generate-music. Returns bpm, key, genre, instrumentation, mood, description, and title based on geographic/cultural analysis of the provided directions.'
No output schema documented for either tool. generate-music is a destructive/WRITE operation that produces audio files but the response structure is not defined. Without documented output, the LLM cannot reason about what fields to expect or chain downstream operations. Should document: 'Returns {audioUrl: string, styleCard: StyleCard, duration: number, format: string}'
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 55 | 2025-06-18+ | v2 |
| 2026-03-09 | F | 40 | - | v1 |
generate-music lacks confirmation/dry-run pattern. It modifies state (creates audio files, may consume API credits via ElevenLabs/Google). The tool should support a 'dry_run' parameter or require explicit confirmation before executing. Currently, agents can trigger expensive operations without recourse.
Parameter descriptions lack format/constraint clarity. 'directions' is described as 'An array of routing directions as strings' but doesn't specify: max length, expected format (turn-by-turn?), example format, or length bounds. 'styleCard' input parameter lacks description of what properties are required vs optional. 'routeGraphics' is marked optional but no guidance on expected structure.
No error handling guidance. If find-musical-style fails to analyze directions (e.g., invalid geography), the error message doesn't guide recovery. If generate-music times out (could take minutes), no retry strategy is documented. Errors should be categorized (retryable vs user-fixable vs fatal) with actionable next steps.
dummyMode parameter (present in both tools) is not well-motivated in descriptions. The LLM doesn't know when to set dummyMode=true vs false, or what the behavioral difference is. Should clarify: 'Set to true to skip actual music generation and return mock data (for testing). Set to false for production generation (may take 5+ minutes).'