Three tools with basic verb-noun naming (list_projects, list_services, get_service_details) but critical gaps in descriptions and schemas. Descriptions are present but generic and lack context for LLM selection. Input schemas exist for 2/3 tools but lack parameter descriptions entirely. No output schemas documented. No error handling guidance. Tool descriptions use string formatting placeholders ('%s') which is anti-pattern for LLM consumption. No pagination support despite list tools. Fails multiple baseline requirements: descriptions under 194 chars average but lack actionable context; zero parameter descriptions violate pattern:tool-description; no output schema documentation violates pattern:tool.

• Add parameter descriptions to all input schemas. Example: 'project_name': {'type': 'string', 'description': 'The Aiven project name (case-sensitive, 1-64 characters)'}
• Document output schemas for each tool. Example for list_projects: 'Returns array of strings, each a project name. Example: ["my-project", "staging-project"]'
• Replace string formatting placeholders in descriptions with clear, LLM-optimized text. Example: 'List all services in a specified Aiven project. Returns service names and types. Call this to discover available services before fetching details.'
• Add pagination to list_projects and list_services: accept 'limit' (default 20, max 100) and 'offset' parameters; return total_count and has_more fields.
• Implement error handling with recovery hints. Catch AivenClient exceptions and return structured errors like: {'error': 'Project not found', 'hint': 'Verify project name with list_projects()', 'available_projects': [...]}

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

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