Spotify MCP has clear naming conventions (verb_noun pattern) and all 10 tools are explicitly registered with descriptions and Zod schemas. However, descriptions are minimal (avg ~60 chars, well below the 194-char baseline), parameter descriptions lack detail about constraints and formats, and output schemas are not documented. Error handling is absent, tools return raw API responses without recovery guidance. The 'spotify-search-and-play' and 'spotify-find-playlist' tools violate single-responsibility principle by combining search+action. No input validation, rate limiting, or permission checks.

• Expand all tool descriptions to 100-200 chars. Include WHAT the tool does, WHEN to use it (vs similar tools), and WHAT it returns. Example: 'Search Spotify for tracks by artist, album, or song name. Returns up to 50 results with ID, name, artist, and URI. Use before spotify-play to find a track by name.'
• Document output schemas for all tools. Specify field names, types, and structure. Example: 'Returns array of {id: string, name: string, artist: string, uri: string, duration_ms: number}.'
• Add min/max constraints to numeric parameters. Example: 'limit: number (1-50, default 20)' instead of just 'Maximum number of results to return (default: 5)'.
• Split 'spotify-search-and-play' into separate 'spotify-search' (already exists) and 'spotify-play' (already exists), remove the composite. Same for 'spotify-find-playlist': use 'spotify-playlists' + 'spotify-play-playlist'.
• Add error handling with recovery hints. Example: 'No tracks found for "xyz". Try a simpler query (artist name only) or use spotify-devices to check if playback is available.'