Single tool with basic structure but significant gaps. Tool name 'search_beatport_artists' follows verb_noun convention (+). Description exists but is minimal (47 chars, below 50-200 char baseline for LLM optimization). Input schema present with type and description for artist_name parameter (+). However, output schema is completely undocumented, the tool returns response.json() or an error dict, but no schema is declared for what fields the LLM should expect. Error handling returns a dict with 'error', 'status_code', 'message' fields, but this structure is not formally documented. No pagination support despite potentially returning multiple artists. No parameter constraints (e.g., min/max length for artist_name). Tool lacks idempotency hints, destructive/readonly annotations, and recovery guidance in error messages.

• Document the output schema explicitly. Specify what fields are returned on success (e.g., artists array with id, name, url, genre fields) and on error (error, status_code, message, suggestion).
• Expand tool description to 80-150 chars. Example: 'Search Beatport's artist catalog by name. Returns matching artists with IDs, genres, and profile URLs. Useful for finding artist info, discography, or verifying artist existence. Supports pagination via limit and offset parameters.'
• Add limit (default 20, max 100) and offset (default 0) parameters to support pagination. Return total_count in response so LLM knows if more results exist.
• Enhance error handling with recovery guidance. Example: 'API rate limited (429). Retry after 60 seconds.' or 'Artist not found. Try a partial name or check spelling.'
• Add constraints to artist_name: min 1 char, max 100 chars, no leading/trailing whitespace. Document in parameter description.

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

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