Single tool with acceptable naming and basic schema, but descriptions lack depth and output schema is not explicitly documented. The tool follows a verb-noun pattern (search_music) which is correct, but the description, while present, is generic and doesn't address when to use this tool vs alternatives or how to handle pagination. Parameters have types and defaults, which is good, but lack detailed constraints. The filtering logic in the implementation suggests the output structure, but there is no formal output schema documentation visible in the code or tool definition.

• Document the output schema explicitly. Add a Returns section to the docstring specifying: 'Returns a list of objects, each with fields: {id: string, mid: string, name: string, pmid: string, subtitle: string, time_public: string, title: string}.'
• Add constraints to numeric parameters: 'num: Maximum number of results to return (default: 20, valid range: 1 - 100)' and 'page: Page number for pagination (default: 1, starts at 1).'
• Enhance the tool description to ~150 - 200 characters and address: (1) What domain is this for (QQ Music)? (2) When would an agent call it (to find songs by artist, title, or keyword)? (3) What format is keyword in (free text, case-insensitive, partial match supported)? Example: 'Search QQ Music catalog for songs by keyword, artist, or title. Accepts free-text queries, case-insensitive. Use for discovering tracks, finding discography, or checking availability. Returns up to 100 results per page.'
• Add error handling: wrap the qqmusic_api call in try-except, catch common failures (network timeout, empty keyword, invalid page), and return structured error messages like: '{"error": "Invalid page number. Page must be >= 1 and <= {max_page}. Try: search_music(keyword=\"...\", page=1)}'.
• Extend the response to include pagination metadata: 'total_count' (total matches found) and 'has_more' (boolean, whether more pages exist). This lets LLMs decide whether to fetch the next page without guessing.