Server has 4 well-structured tools with complete JSON Schema definitions and reasonable descriptions. All tools follow verb_noun naming (generate_bgm, get_bgm_variations, adaptive_layer_control, scene_transition_music). Schemas include proper type constraints, enums, and parameter descriptions. However, descriptions are generic and lack LLM-optimized guidance on WHEN to use each tool vs. alternatives. Output schemas are not documented, LLMs cannot predict response structure. Error handling is minimal (generic try/catch). No tool annotations (destructiveHint, idempotentHint). Parameter descriptions lack actionable constraints (e.g., 'duration_seconds' says '10-300' but doesn't explain why or when to pick values in that range).

• Document output schema for each tool. E.g., generate_bgm returns {audio_url: string, share_link: string, integration_code?: string, duration_seconds: number}. Include field descriptions so LLMs know what to extract.
• Expand tool descriptions to 100-150 chars with WHEN guidance. E.g., 'generate_bgm: Create new game music from scratch. Use when you need a fresh track for a scene. Use get_bgm_variations instead if you want to remix an existing track.'
• Add tool annotations: mark all 4 tools with destructiveHint=true (they call external APIs and generate music). Mark generate_bgm and scene_transition_music with idempotentHint=false (repeated calls create new tracks).
• Enhance parameter descriptions with actionable constraints. E.g., 'duration_seconds: Track length in seconds. Use 30-60 for loops, 10-20 for stingers, 60-120 for exploration. Default 60.'
• Implement structured error responses with recovery guidance. E.g., {error: 'API rate limit exceeded', retryable: true, retry_after_seconds: 60, next_step: 'Wait 60 seconds and retry, or call get_bgm_variations with a different share_link'}.

Inferred effective spec: <=2025-11-25.

• Relies on Logging (deprecated) - log to stderr or use OpenTelemetry