The server implements 3 read-only tools with clear action verbs and reasonable descriptions. All tools have input schemas with type definitions and parameter descriptions. However, there are notable gaps: output schemas are not formally documented (responses are JSON-stringified text), some parameter descriptions are terse, and error handling lacks recovery guidance. The tools follow single-responsibility principles and compose well, but output formatting could be more structured for downstream LLM consumption.

• Formalize output schemas. Define return types for each tool: e.g. genius-search-song returns {hits: {title, artist_id, song_id}[], total: number}. Document this in tool descriptions or a separate schema registry so LLMs understand what fields to extract.
• Enhance error messages with recovery hints. Instead of 'Error executing search in Genius: <error>', return 'Search returned no results for "<query>". Try a shorter or more general query, or check the artist name separately with genius-list-artist-songs.' This guides the LLM's next action.
• Expand parameter descriptions to include valid ranges, resolution strategies, and mutual exclusion hints. For artistId, add: '(Numeric ID; if you only have the artist name, call genius-search-song first and extract artistId from the result.)'
• Add explicit pagination guidance. Document that perPage is capped at 50 and is required for datasets larger than ~100 songs. Explain that default behavior returns the first page; instruct LLM to loop with page parameter if exhaustive results are needed.
• Clarify the relationship between genius-song-lyrics tool and genius://songs/{id}/lyrics resource. If they return the same data, explain which to prefer and why. If different, clarify the use case for each.
• Add result size limits and defaults. Cap genius-list-artist-songs to first 20 results by default (perPage=20) even if user doesn't specify, to prevent context bloat. Document this cap in the tool description.