Significant structural and naming issues undermine quality. Tool definitions lack consistency: 3 duplicate names (add_expense, get_expenses_data, analyze_spending_prompt appear twice; call_create_customer_api appears twice). Descriptions are present but generic (avg ~60 chars, below 194-char baseline). Parameter schemas are visible but lack depth, most params have minimal descriptions. No error handling guidance, no output schema documentation, no tool annotations. The server mixes CSV and Cosmos DB backends without clear separation. STDIO transport limits remote accessibility.

• Consolidate duplicate tools: merge CSV and Cosmos DB variants into single tools with a 'backend' parameter or separate servers with distinct names (e.g., add_expense_csv, add_expense_cosmos).
• Expand tool descriptions to 100-200 chars. Include WHEN to use, WHAT it returns, and any prerequisites. E.g., 'Retrieve all expenses from CSV. Call this first to see available categories before filtering. Returns list of {date, amount, category, description, payment_method}.'
• Document output schemas explicitly. For get_expenses_data, specify: 'Returns CSV text with columns: date (YYYY-MM-DD), amount (number), category (enum), description (string), payment_method (enum).'
• Add descriptions to all parameters. For 'payload' in call_create_customer_api, specify: 'CreateCustomerRequest object with fields: first_name (string), last_name (string), email (string), phone (string), gender (M|F).'
• Implement error classification and recovery hints. E.g., 'File not found: customers_data.csv does not exist. Ensure CSV is initialized before calling this tool.' or 'Duplicate email detected. Try search_customers() to find existing customer.'

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

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